Essential Forms

hcgtv · 2011-01-19 14:01:52

thebombsite wrote:

I was thinking that any theme is still a theme, whether it be the default theme shipped with Txp or otherwise, so why couldn’t it be hosted on Textgarden with the rest of them?

No reason it shouldn’t be hosted at Textgarden, but I think it still should ship with the core files.

wet wrote:

I disagree and prefer convention over configuration.

From a templating point of view, hard coded forms makes it hard to have true click and run scenarios. You’re still instructing the end user to copy/paste your customized error page into the hard coded error_default page and so on.

That is all I was saying about hard coded forms, and if you’re heading into the support arena, don’t you feel that all these forms are confusing to the end user?

wet · 2011-01-19 14:44:27

hcgtv wrote:

You’re still instructing the end user to copy/paste your customized error page into the hard coded error_default page and so on.

I don’t think I understand your concern. There’s nothing I can see which hinders a sophisticated templating mechanism from operating under these boundary conditions and install a page named ‘error_default’ et cetera.

zem’s Themes page is still relevant. “Install and uninstall should be easy and non-destructive” could be accomplished with two approaches:

Use a separate namespace for each distinct theme: Maybe this would require configuration over convention for page and form names, but I do not see the absolute necessity.
Any other means like e.g. expanding the current object model for preferences, plugins, pages, and forms: This would even work with the current fixed names for default forms or pages.

maverick · 2011-01-19 15:20:03

wet wrote:

Use a separate namespace for each distinct theme:

This is definitely my preferred way forward.

Thinking aloud (always dangerous, and perhaps a bit dense ;) )

I see the need to have defaults that are there out of the box, and can see a plus if they are there to fall back on in case something gets messed up and you need to quickly make it work again while being fixed. I also like the idea of having as few presentation things hard coded as possible. I’m uneasy though at the idea of doing this so that theming mechanisms can overwrite defaults automatically.

Being able to have a one-click install that overwrites the default forms has great convenience, and would useful much of the time, yet, I think it would also be “one note” as well as “one click”.

There are times that I am running more than one theme on the same site (for example, one of the churches wanted something very different looking for their kids sections and again for the youth sections – so each felt like it had it’s own distinct website. But could all be administered from the same back end.

Again, in another scenario – I wish to install a new theme to play with, and see what I think, but am not ready to commit to using.

The ideal way for it to work would be more like smd_admin_themes — where I could install the theme, click on the theme from a master theme page, and the site switches over. If I don’t like it, I click on the old theme and everything is restored.

I realize that a one click theme control like that may not be in order given the pages/forms flexibility, (or maybe with some creative association method it could be), but either way, to test a new theme out while retaining the old theme requires both to be present — not to have the new overwrite the old.

If I wanted to use a one-click install for each theme, and it was over writing each theme as default it would no longer be a “one click install” in these situations. I’d have to manually rename everything because they require themes to use a prefixed name to keep the themes separate.

Thus, in order to accommodate such scenarios it would also mean that you would not be able to have the default forms automatically overwritten. If they are not automatically updated on theme install, then you would need to keep them as default, and separately named even if not hard coded.

.

Last edited by maverick (2011-01-19 15:24:04)

hcgtv · 2011-01-19 15:53:20

wet wrote:

There’s nothing I can see which hinders a sophisticated templating mechanism from operating under these boundary conditions and install a page named ‘error_default’ et cetera.

As Mike points out, there should be the means to have more than one theme installed at one time. I don’t feel comfortable with overwriting the defaults or whatever the user might have installed.

Let’s look at a real simple template called Terrafirma:
Pages – terrafirma
Forms – article, head, sidebar, footer
Style – terrafirma

As you can see, the Pages and Style is named terrafirma, not a big chance of collision with an installed theme. It’s when you get to the forms, that you’re likely to collide with a sidebar or footer form from another template.

A real drop dead simple approach to this would be to use the Form Type to designate a template set. I’ve brought this up before, the Type is not used for anything and could easily be used to group template related forms, and with 4.3.0, we can expand and collapse on Type.

Yes, you could go the route of terrafirma_head, etc., but it’s gets real confusing as you install multiple templates in the backend, all these forms grouped under Article let’s say, which one am I using, oh damn I changed the wrong one, been there, done that.

All I’m saying is that with a few tweaks here and there, you have a templating system in place, using the existing backend. That’s how I would approach it, minimal changes by using what is offered to me by the current code base.

thebombsite · 2011-01-19 16:08:02

hcgtv wrote:

No reason it shouldn’t be hosted at Textgarden, but I think it still should ship with the core files.

I totally agree. Wasn’t trying to suggest otherwise. I just think Textgarden is the proper place for it rather than Documentation which is where it currently resides.

I mean, if ever the commenting system were to became an “approved” plugin which was installed with Txp (just an example you understand) you wouldn’t host it on Documentation, you would host it on Resources where it belongs.

maverick

For a theme to work at the moment there are certain “essential” forms that HAVE to be overwritten because Txp will use nothing else. I’m thinking of comment_display, comments and comment_form to name 3 straight off. The comment system is so tied up in knots that the only form I can think of that you could give any name to that you wanted would be for preview.

Of course, as far as things like the default form are concerned, you don’t have to use it. You can supply your own form for that one but then you are still stuck with a default form that cannot be deleted, so it simply becomes a waste of space. Might as well go for that tiny little bit of extra coding that Robert seems to disapprove of.

At the moment, with any of my themes, rather than waste an “essential” form, I use it, including default and the error_default page template. Also, when installing one of my themes, via a plugin, a backup of the existing sections, page templates, form templates, style templates and plugins is taken before any importing is done. If you don’t like what you have just imported you simply re-import the backup.

Having a system similar to Stef’s admin_themes plugin sounds great but I suspect it would reduce TXP to the flexibility of a blogging platform the name of which I shan’t mention. We wouldn’t want that now would we? ;)

maverick · 2011-01-19 19:08:03

`*thebombsite wrote:*

For a theme to work at the moment there are certain “essential” forms that HAVE to be overwritten because Txp will use nothing else.

Understood. There have been times when I have wished there was an option, when a form is necessary for a site to work properly, to mark which form is to be used as “default” by section/page, to further allow differentiated designs on a single site rather than having a single form with some sort of conditional trickery and overrides.

Agreed comments in general, and comment related forms in particular could stand improvement and flexibility.

you are still stuck with a default form that cannot be deleted, so it simply becomes a waste of space.

It’s not clean, but it doesn’t take up much space ;)

when installing one of my themes, via a plugin, a backup of the existing sections, page templates, form templates, style templates and plugins is taken before any importing is done.

Which I greatly appreciate!

The one drawback is that doesn’t help with multiple themes at once. I’ve taken to the clumsy practice of using prefixes, but as Bert points out, it can become confusing with main_theme_head, kids_theme_head, youth_theme_head, etc.

If you don’t like what you have just imported you simply re-import the backup.

Which is not quite as simple and quick as a “smd_admin_theme type” switching back and forth, but is about as close as one can get right now. Just slightly more time and effort.

I suspect it would reduce TXP to the flexibility of a blogging platform the name of which I shan’t mention.

That would be my fear as well. Thus my reference to the pages/forms where in lies so much wonderful Txp gooey goodness :)

In addition I am of the camp that likes having most everything in the database. Then using something like rvm_css when static options are desired. As is smd_admin_themes uses directories. A design like that would make it easier to edit w/ external editors, etc. but lose the database advantage (I know – there are those that would argue whether its an advantage).

We wouldn’t want that now would we? ;)

;D — so very very true.

maverick · 2011-01-19 19:09:15

hcgtv wrote:

All I’m saying is that with a few tweaks here and there, you have a templating system in place, using the existing backend. That’s how I would approach it, minimal changes by using what is offered to me by the current code base.

Hmmm. Thinking . . . . :)

maverick · 2011-01-19 20:34:12

thebombsite wrote:

I suspect it would reduce TXP to the flexibility of a blogging platform the name of which I shan’t mention.

Got sidetracked earlier — I was going to also add: If losing the flexibility was the trade off, it would not be worth it. But we have some really talented people around here. It’s possible they might figure out a way make it work.

The two thinks I really like about smd_admin_themes

One Click install/change
when editing the theme, the way things are grouped together, and how easy it is to add, delete files.

Last edited by maverick (2011-01-19 20:34:32)

hcgtv · 2011-01-19 21:35:37

maverick wrote:

Got sidetracked earlier — I was going to also add: If losing the flexibility was the trade off, it would not be worth it. But we have some really talented people around here. It’s possible they might figure out a way make it work.

I don’t see how making it easier for a new user to start off his/her site would make it less flexible to the advanced user.

Maybe I’m missing something, since I’ve never quite understood the political wrangling to keep things as they are.

thebombsite · 2011-01-19 21:40:08

Indeed Mike I would also prefer to retain Txp’s flexibility even if that is traded off against simpler theme installs.

Once the new plugin goes to full release so I can update my existing themes and use it for new ones, all themes will be contained within their own directory within the template directory.

With the exception of those “essential” forms that need to be used, all other forms within a theme use a prefix, however, as you say, if you have a site where there is more than one theme in concurrent use, there can certainly be some confusion. I have to say though, that kind of set-up must be quite rare and it is certainly not something I have thought of when producing themes.

Last edited by thebombsite (2011-01-19 21:41:14)

maverick · 2011-01-19 21:58:09

hcgtv wrote:

I don’t see how making it easier for a new user to start off his/her site would make it less flexible to the advanced user.

That was in reference whether or not the approach that smd_admin_themes uses could be transferred to a templating system of pages and forms without losing some of the flexibility. Not being a php person I don’t know if it can or cannot.

I’ve never quite understood the political wrangling to keep things as they are.

me- I’m for change more often than not. Sometimes even for no other reason that to keep things fresh :).

I think that for me the idea of whether the change is worth it comes down to the assessment of what is being gained versus being what is being lost. If the gain is worth what is sacrificed, then it needs serious consideration.

I really respect the value Txp has had for backwards compatibility. However, I also believe that value can’t be the driving value, or progress grinds to a halt. Some parts of the future just are not compatible with the past. I’m excited about Txp 5 because I suspect that while compatibility is still important, there’s going to be more weight on reposition for the future.

I think the ease and flexibility/power often require some compromise, but I don’t think they are incompatible. The new cxc_template shows promise to that end. I was trying it out earlier today, and except for a minor upload issue it really was simple, and fast.

Last edited by maverick (2011-01-19 22:02:00)

maverick · 2011-01-19 22:04:41

thebombsite wrote:

that kind of set-up must be quite rare

quite probable that it is. I only have had a few cases where it was needed. More often I run into it when trying out various themes, or developing new ones.

hcgtv · 2011-01-20 01:51:29

thebombsite wrote:

With the exception of those “essential” forms that need to be used, all other forms within a theme use a prefix, however, as you say, if you have a site where there is more than one theme in concurrent use, there can certainly be some confusion. I have to say though, that kind of set-up must be quite rare and it is certainly not something I have thought of when producing themes.

I imagine you use one Textpattern install to create one theme, or maybe you save it off and clear things before starting the next one? In my own experience, once you get to the third template you’re working on, it gets very, very confusing.

This is counter-productive, not being able to have multiple templates in the back-end and I’ll give you a good example. When you’re creating templates from XHTML layouts, and the layouts come from the same author, code reuse is very important to speed things up. Pages will be very similar, since they tend to use the same div id’s and such. Forms especially, since footers, headers, side-bars will also be similar. What usually differentiates each design is the color scheme found in the style.

I invite you to try out the Nucleus CMS demo, sign on to the admin and click on Skins. There’s only the default installed, but if you add a new one, it neatly keeps all pages grouped together. Quick tutorial – Skins are Pages, Templates are reoccurring Forms like what txp:article would use and clicking on Skin Files takes to the asset directory, which has include Forms, like footer, header – similar concepts, just different wording and methodologies. Click on Import/Export, you can pick and choose what to export, unlike our plugins that export everything under the sun, necessitating the one install per theme creation scenario.

What I’ve been discussing for the last 4 years is not rocket science, nor do we have to dip into assembler language to make it happen. All we need to do is look around at what everybody else is doing to realize that even though our logo is a chisel and hammer, there are fountain pens these days.

thebombsite · 2011-01-20 11:31:39

Well at the moment Bert I do create themes individually though that is because the development site becomes the “demo” once I go public with it. My only “saving” is that I use a table prefix so that I can use a single database for many demo sites.

My other demo site uses a single install so I am well aware of the confusion that can be caused by having many themes within a single instance of Txp.

Having read Stef’s latest post vis a vis Txp5 I’m not sure I want to start changing my method until I can get my hands on an alpha or beta or whatever and start playing with it.

hcgtv · 2011-01-20 15:32:03

thebombsite wrote:

Well at the moment Bert I do create themes individually though that is because the development site becomes the “demo” once I go public with it. My only “saving” is that I use a table prefix so that I can use a single database for many demo sites.

Yes, that’s the issue I’m facing with the new templates site that I’m working on. I’d hate to have a separate install per template, cause it can quickly turn into a maintenance headache. Another option is to use the multisite capabilities that Sam contributed, which gives you one code base, with multiple databases, but that can also turn into a major pain in the neck once you get over 50 templates.

Textpattern CMS

Textpattern CMS support forum

#16 2011-01-19 14:01:52

Re: Essential Forms

#17 2011-01-19 14:44:27

Re: Essential Forms

#18 2011-01-19 15:20:03

Re: Essential Forms

#19 2011-01-19 15:53:20

Re: Essential Forms

#20 2011-01-19 16:08:02

Re: Essential Forms

#21 2011-01-19 19:08:03

Re: Essential Forms

#22 2011-01-19 19:09:15

Re: Essential Forms

#23 2011-01-19 20:34:12

Re: Essential Forms

#24 2011-01-19 21:35:37

Re: Essential Forms

#25 2011-01-19 21:40:08

Re: Essential Forms

#26 2011-01-19 21:58:09

Re: Essential Forms

#27 2011-01-19 22:04:41

Re: Essential Forms

#28 2011-01-20 01:51:29

Re: Essential Forms

#29 2011-01-20 11:31:39

Re: Essential Forms

#30 2011-01-20 15:32:03

Re: Essential Forms

Board footer