Essential Forms

thebombsite · 2011-01-19 11:24:50

Any chance you might explain your preference please Robert?

wet · 2011-01-19 11:31:50

E.g.:

Conventions allow for less code, both for core developers and site builders.
Conventions are an easy base for support questions (As in “Please post the contents of your ‘default’ article form” vs. “Please post the form whose name you find in the page template which is named in the ‘sections’ tab for the section you have set as default in your site preferences”

~cXc~ · 2011-01-19 12:02:58

The support question responses need not be that complicated …

“Please post the contents of your ‘default’ article form”
“Please post the contents of the article form you have selected as ‘default’ in site preferences”

… as an example, but I see your point, I think the ‘default’ forms should be considered ‘essential’ but currently I think there are more forms than there should be.

In an ideal world non-essential files wouldn’t be included with a core installation at all … but that’s also my opinion I suppose o.O

I see the point being made for no hard coding but I don’t see it as realistic … some things should be hard coded just to simplify support and make sure sites function properly … you have to account for user stupidity (and people like me o.O)

Last edited by ~cXc~ (2011-01-19 12:04:59)

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.

Textpattern CMS

Textpattern CMS support forum

#13 2011-01-19 11:24:50

Re: Essential Forms

#14 2011-01-19 11:31:50

Re: Essential Forms

#15 2011-01-19 12:02:58

Re: Essential Forms

#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

Board footer