Move presentation layer to file system

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)

zem · 2006-01-19 02:37:12

Just FYI, there’s a new FAQ entry that’s relevant here.

andreizinca · 2006-01-22 18:41:34

I have UNDO in my textarea because I’ve hacked textpattern to use AJAX so there is no page refresh when saving css, which enables UNDO. Also the cursor position does not change between saves, which is the biggest time saver.
This way I have created an entire css file using just TextPattern.

This AJAX technique can be applied also to article editing.

Last edited by andreizinca (2006-01-22 22:47:44)

mrdale · 2006-01-22 19:08:17

adrezinca> Care to document this.

After getting sick of scrolling through my css file over and over again, I finally started using this technique. Your solution, is better, of course.

Code coloring would also be nice though.

Last edited by mrdale (2006-01-22 19:09:24)

Destry · 2006-01-22 20:15:44

andreizinca wrote: I have UNDO in my textarea because I’ve hacked textpattern to use AJAX so there is no page refresh when saving …

This does sound good. The jump back to the top of the box is indeed a pain in the arse for me often.

andreizinca · 2006-01-22 21:43:38

> mrdale wrote:
> adrezinca> Care to document this.
>After getting sick of scrolling through my css file over and over again, I finally started using this technique. Your solution, is better, of course.
>Code coloring would also be nice though.

Yes, splitting css is actually a nice thing to do for keeping it organized.
I also created master templates by nesting forms.

As for the AJAX method I am using, I have made modifications in many places in the source code and I do not remember all of them.
I’ll try to make a diff from the original textpattern against my source and see all the modifications.

EDIT:

Yes, there are a lot of modifications. :) It would take a while documenting every change.

But, if you are brave, you may use the patches I have created for the 4.0.2 version of TextPattern

Test it and port it afterwards to your application if you like it.

I make use of tw_sack.js wich can be found here You must copy tw_sack.js to you application folder

Good luck and tell me what you think!

Last edited by andreizinca (2006-01-22 22:47:17)

gravyface · 2006-01-25 04:20:43

Interesting workaround with that AJAX. I think I’ll stick with my original plans to move the templates and css to the file system though. Has anyone tried any tinyMCE or HTMLArea integration? The TXP dialect is pretty nice but I know they’ll be some users who’ll want that Word-like interface for editing.

Taking that Word dependency further, is there any Word to TXP converters in the works? A few of my clients will undoubtedly have quite a few Word documents they’ll want to import into TextPattern.

thebombsite · 2006-01-25 07:04:38

hak_tinyMCE

I’m sure I read something about a “Word” converter but I’m buggered if I can remember where.

mrdale · 2006-01-25 16:12:41

andreizinca> Thanks for the info. I’m not brave enough to start any major hacking. What you did sounds cool though.

KurtRaschke · 2006-01-30 02:40:50

> thebombsite wrote:

>I’m sure I read something about a “Word” converter but I’m buggered if I can remember where.

Perhaps you were thinking of Dean’s Word HTML Cleaner?

-Kurt

Textpattern CMS

Textpattern CMS support forum

#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

#16 2006-01-19 02:37:12

Re: Move presentation layer to file system

#17 2006-01-22 18:41:34

Re: Move presentation layer to file system

#18 2006-01-22 19:08:17

Re: Move presentation layer to file system

#19 2006-01-22 20:15:44

Re: Move presentation layer to file system

#20 2006-01-22 21:43:38

Re: Move presentation layer to file system

#21 2006-01-25 04:20:43

Re: Move presentation layer to file system

#22 2006-01-25 07:04:38

Re: Move presentation layer to file system

#23 2006-01-25 16:12:41

Re: Move presentation layer to file system

#24 2006-01-30 02:40:50

Re: Move presentation layer to file system

Board footer