Move presentation layer to file system

gravyface · 2006-01-18 02:23:38

I’m not sure if this is the right forum for text pattern design/architecture discussions, but here goes:

I’m wondering why it was decided to move the css and page templates to a database. Not only is it more difficult to build a new template from scratch, it also makes it (arguably) more difficult to install a template. You can’t argue that a good IDE or text editor is light years ahead of a textarea field: undo, syntax highlighting, and version control are just a few reasons why.
Secondly, I’d argue that file system performance would be better, because relational databases are generally optimized for many random/complex queries against large, structured data sets, while file systems are more apt to handle fewer, simpler queries of smaller, unstructured data sets.

I realise that not every user has access to the file system and I can see why channeling end-user/author access through a well-defined, form-based interface is a good idea. However, using other Web CMSs, forums, and blogs as an example, you rarely find that the initial design phases of a site need to be confined to a form-based approach for developing the presentation layer — designers are used to working with text files and images on disk.
The best approach is to use a development environment (usually on the desktop or a dev server in a corporate environment) first, to get the “learning curve” out of the way, and to mitigate the risks associated with working “live”.

I do have several options:

- Create a static “site” first and copy/paste it into Text Pattern, but this leaves opportunities for errors (links, image paths) and redundancy.

- Refactor Text Pattern to read the presentational data from disk.

For now, I’m leaning towards just creating a static copy of the site first but I’m considering the second option longer term.

I’d like to hear what other developers/designers have to say on this before I do anything.

Thoughts?

On another note, Text Pattern is great — the txp “dialect” is one of the best markup mini-languages I’ve used (the defacto “standard” that has grown popularity in the wiki crowd pales in comparison, imho) and the simpicity of the user interface and workflow is one of the reasons why I’m choosing this for an online magazine over some of the more “powerful” Web CMS/portals out there.

KurtRaschke · 2006-01-18 02:47:40

Well, one advantage I see offhand to storing everything in the DB is that it makes backup, restore, and moving between servers a cinch—just dump/restore the DB. Also, storing pages/forms in the filesystem means that users have to deal with FS permissions. Users seem to have enough trouble with permissions in getting TXP image and file uploads to work—questions like “What’s chmod?”, “How do I chmod 777 in Windows?”, etc.

Personally, I don’t use an IDE for HTML, but I can see how they could have their advantages.

However, rather than moving the presentation layer to the FS, which would require a lot of overhauling, what I might recommend would be to add a WebDAV server to TXP. The WebDAV server component would export TXP pages and forms as files in a WebDAV share, such that they could be opened and edited with a desktop editor.

There is a beta WebDAV server class for PHP, so it’s certainly possible to write a WebDAV server in PHP. Integrating it with Textpattern, though, would be another thing entirely.

It’s something to explore.

-Kurt

Last edited by KurtRaschke (2006-01-18 02:49:05)

misterk · 2006-01-18 03:11:43

I used MT for a bit before finding textpattern, and the one thing I miss is how it straddled templates both in the database (editable from within the MT admin section) and in the filesystem. I’d love if textpattern could figure this out, I’d be in love.

gravyface · 2006-01-18 03:12:31

Well, one advantage I see offhand to storing everything in the DB is that it makes backup, restore, and moving between servers a cinch—just dump/restore the DB.

I agree with you in principle but the images are still on the file system so while you’re accounting for those files in your backup routine, how much harder is it to add a handful of text files?

Also, storing pages/forms in the filesystem means that users have to deal with FS permissions. Users seem to have enough trouble with permissions in getting TXP image and file uploads to work—questions like “What’s chmod?”, “How do I chmod 777 in Windows?”, etc.

Again, in principle yes, but you have to chmod the permissions on the Text Pattern config file, and/or the images directory, so why would a few template files be any different? And in Windows, you wouldn’t even have to change the file permissions on 99% of Windows desktops out there.
The bottom line is Web Designers are used to working with files on a file system which is why I think this is a good idea for usability and getting “buy-in” from them.

However, rather than moving the presentation layer to the FS, which would require a lot of overhauling, what I might recommend would be to add a WebDAV server to TXP. The WebDAV server component would export TXP pages and forms as files in a WebDAV share, such that they could be opened and edited with a desktop editor.

That might be a better option but I wonder how difficult that would be to integrate compared with reading a file from disk vs. db. I’ll have to investigate further.

Thanks for the feedback.

takshaka · 2006-01-18 04:27:41

There is a beta WebDAV server class for PHP, so it’s certainly possible to write a WebDAV server in PHP. Integrating it with Textpattern, though, would be another thing entirely.

That would be nice. It’s also as likely to happen as Txp dropping PHP and moving to Rails.

zem · 2006-01-18 05:25:10

I’d like to hear what other developers/designers have to say on this before I do anything.

Premature optimization is the root of all evil.

This is open source, you don’t need anyone’s permission to change something.

Jeremie · 2006-01-18 09:02:05

I don’t see why TXP couldn’t doo (by itself or with a plugin) an XML import/export of templates (sections, pages, forms, css, etc.), and import from plain text for example. Writing such a plugin shouldn’t be that hard, no ?

hakjoon · 2006-01-18 13:23:05

swf had a script that would do it. Last report was that it had problems with 4.0.3 but it used to work. Could be a starting point for a plugin. The thing that makes the MT feature so nice is that it’s automatic.

Last edited by hakjoon (2006-01-18 13:24:38)

thebombsite · 2006-01-18 22:09:06

I like it the way it is thankyou. Very easy to move a site. I have to do a lot of that with my other interest and I can assure you that compared to TXP, moving a WP site is a PITA.

As for development I do that using a Xampp install. No problem there and I have no fear of copy/pasting templates across. Syntax highlighting? What’s that then? Do you really need pretty coloured text to see your errors? I think not.

swf · 2006-01-18 22:09:29

Someone please take what I’ve made and improve it and make it into a plugin.

I would love to but I’ve been so busy (teacher) that I have forgotten so much of the little bit of php i knew (does that make sense? ‘so much of the little i knew’).

gravyface · 2006-01-18 23:48:51

thebombsite wrote:
> I like it the way it is thankyou. Very easy to move a site. I have to do a lot of that with my other interest and I can assure you that compared to TXP, moving a WP site is a PITA.
As for development I do that using a Xampp install. No problem there and I have no fear of copy/pasting templates across. Syntax highlighting? What’s that then? Do you really need pretty coloured text to see your errors? I think not.

How exactly is Xampp (a MySQL, Apache, PHP installer) going to address the issue?

Not everyone is a seasoned veteran who “doesn’t need no stinkin’ editor!” and uses vi on the command line. Some beginners may want to use Dreamweaver or TopStyle Pro for their editing. Adding additional steps — building a static mockup first and then dissecting/pasting it in the right textarea field — can be daunting for a new user.

Personally, I use Ultraedit, but I find the biggest slow down with the current interface is having to scroll down and hit ‘save’ after making my changes. It doesn’t seem like a big deal for one-off changes, but when you’re used to keyboard shortcuts (CTRL-S, ALT-TAB, etc.) and you’re designing iteratively, it is a bottleneck. And what about search/replace? Undo? Even TAB doesn’t work (I like my code readable) — the list goes on and on — so I don’t think you can argue that an editor is better than a textarea field.

Seeing as there is some interest here, I think I’m going to look into putting together a plugin that will allow templates to be stored on the file system.

gravyface · 2006-01-18 23:50:57

> hakjoon wrote:

> swf had a script that would do it. Last report was that it had problems with 4.0.3 but it used to work. Could be a starting point for a plugin. The thing that makes the MT feature so nice is that it’s automatic.

Just saw this now. I’d definitely be interested in expanding/improving on this. Thanks :)

KurtRaschke · 2006-01-19 00:11:56

How exactly is Xampp (a MySQL, Apache, PHP installer) going to address the issue?

By providing a local development environment, where changes can be tested in isolation (and copy and paste work just fine for getting content in and out).

Even TAB doesn’t work (I like my code readable) — the list goes on and on — so I don’t think you can argue that an editor is better than a textarea field.

There was a plugin to make tab work—one of Mary’s plugins, I think. Besides that, it’s a matter of perception. I grew up with text-mode editors, and I’m still very comfortable with text-mode editors and command line tools. Yes, I do use vi on occasion, and I would certainly argue that a simple text editor like vi or a plain textarea is far superior to a sluggish GUI IDE with all sorts of bells and whistles to get in the way of writing code. I have to admit I’m with Stuart on this one—it seems like unnecessary complexity, when if you absolutely can’t/won’t use TXP’s interface, copy and paste are certainly available.

Seeing as there is some interest here, I think I’m going to look into putting together a plugin that will allow templates to be stored on the file system.

I doubt you’ll be able to make it work as a plugin—it’s going to take hacking the core code, which of course puts it in that perilous position of potentially breaking with every new release.

From a technical standpoint, though, file_get_contents() and file_put_contents() will make the code relatively easy. What I’d recommend is simply rewriting code that accesses txp_page or txp_form to use file_get_contents() and file_put_contents() to get/set data rather than safe_field() and safe_update(). If you do that you can preserve TXP’s interface for editing forms and templates—they’ll just edit the corresponding files, rather than the appropriate rows in the DB.

Now then, what about locking? User A logs in to the TXP web interface and begins editing a page. User B uses FTP to upload a new version of the page. User A hits ‘save’ in the TXP web interface, thus saving their version over User B’s changes. In all fairness, though, there’s no reason why that couldn’t happen with User B using the TXP web interface as well—as far as I know TXP simply doesn’t handle locking at all for form and page changes.

As to a unified system for template import/export, I’m all for that. The present solution (with a folder full of files and instructions for users to copy and paste things into the right places) is not exactly ideal.

-Kurt

Last edited by KurtRaschke (2006-01-19 00:16:54)

thebombsite · 2006-01-19 00:56:46

Importing and exporting themes as a plug-in is being worked on.

gravyface · 2006-01-19 01:52:17

I doubt you’ll be able to make it work as a plugin—it’s going to take hacking the core code, which of course puts it in that perilous position of potentially breaking with every new release.

Then hacking the core it is! :)
I would say that every plugin runs a risk of being broken with every new release, depending on how the core development team is on backwards-compatibility and APIs, but I completely agree with you: it is a risk and one that I feel is acceptable, especially if I intend to use Textpattern for all my clients. Diff and Patch makes life a little easier too. :)

From a technical standpoint, though, file_get_contents() and file_put_contents() will make the code relatively easy. What I’d recommend is simply rewriting code that accesses txp_page or txp_form to use file_get_contents() and file_put_contents() to get/set data rather than safe_field() and safe_update(). If you do that you can preserve TXP’s interface for editing forms and templates—they’ll just edit the corresponding files, rather than the appropriate rows in the DB.
Now then, what about locking? User A logs in to the TXP web interface and begins editing a page. User B uses FTP to upload a new version of the page. User A hits ‘save’ in the TXP web interface, thus saving their version over User B’s changes. In all fairness, though, there’s no reason why that couldn’t happen with User B using the TXP web interface as well—as far as I know TXP simply doesn’t handle locking at all for form and page changes.

I’m going to completely eliminate the database from the template designing/editing equation. txp_page, txp_form, txp_css, etc. will exist in a sub-folder of a /templates folder:
/templates/CorporateCyan
/templates/BloggerBlue

I’m going to create an admin screen where you can enable/disable/preview each template. Essentially, this admin screen will recurse the templates folder and display a list of available templates. I believe this is how Drupal does it for templates and modules, among others.

As a designer creating a new template, all you have to do is create a new sub-folder, copy/paste the txp_* template files into it, and start editing it using whatever text editor you want — just like building a static site. To preview your changes, hit save, and refresh your browser — no update/insert into the database is necessary.

To “export” it, just zip it up. To “import” it, extract it into your production environment’s /templates folder. Same goes for sharing with others: no instructions necessary, just unzip.

This isn’t anything new — this is the defacto standard for hundreds of open source (and probably proprietary) CMSs, portals, blogs, forums, etc.

As for template locking, another argument for a file-based template system — native file locking is not exactly powerful but a version control repository is. Using a stable, mature version control system is ideal and, once again, allows the Site Admin to use whatever they want (CVS, Subversion, StarTeam, SourceSafe, etc.) while allowing TextPattern to remain simple and elegant and not have to add more logic and complexity to the core to handle it.

Last edited by gravyface (2006-01-19 01:53:23)

Textpattern CMS

Textpattern CMS support forum

#1 2006-01-18 02:23:38

Move presentation layer to file system

#2 2006-01-18 02:47:40

Re: Move presentation layer to file system

#3 2006-01-18 03:11:43

Re: Move presentation layer to file system

#4 2006-01-18 03:12:31

Re: Move presentation layer to file system

#5 2006-01-18 04:27:41

Re: Move presentation layer to file system

#6 2006-01-18 05:25:10

Re: Move presentation layer to file system

#7 2006-01-18 09:02:05

Re: Move presentation layer to file system

#8 2006-01-18 13:23:05

Re: Move presentation layer to file system

#9 2006-01-18 22:09:06

Re: Move presentation layer to file system

#10 2006-01-18 22:09:29

Re: Move presentation layer to file system

#11 2006-01-18 23:48:51

Re: Move presentation layer to file system

#12 2006-01-18 23:50:57

Re: Move presentation layer to file system

#13 2006-01-19 00:11:56

Re: Move presentation layer to file system

#14 2006-01-19 00:56:46

Re: Move presentation layer to file system

#15 2006-01-19 01:52:17

Re: Move presentation layer to file system

Board footer