12 replies to this topic

[mikef]

It would be useful to have a spare field on each page that is unused in the default etomite install and the snippets supplied with it.

This would allow developers to make use of this field to store additional data for whatever purpose they want to use it for. (For example you might want to identify a few pages as belonging to a specific group which needs a minor change in a template; at present you either have to maintain two templates, or have to maintain a list of page ids in a snippet that switches the two output forms.)

(you can thank PaulD for this suggestion, indirectly! He mentioned Dean's AliasChunk snippet, which I'd missed, and I immediately thought I could make use of it ... until I realised that I'd need several identical aliassed chunks for pages that need the same changes.)

[Ralph]

As some here are no doubt aware, I use content templates on at least one site... My main development site uses them but they are snippet based and driven off the parent folders id... The one major downfall, if it's really a downfall, is that you have to manually maintain the content template logic by editing the Snippet code... The content templates are actually Chunks... I have entertained the use of content templates in the next major release but wasn't sure how many others would take advantage of them... I'm not sure whether they'd solve more problems than they'd create so I'm open to any input that anyone has regarding their integration...

[mikef]

Currently I have a snippet called from the main template in a few sites that advertises RSS feeds on the pages that have a feed to advertise. (This needs to be in the header, not the body, so can't really go in the page 'content' field. I could use such a new field to control this snippet, rather than relying on me remembering to update the snippet whenever a new RSS feed is created or when one is removed.
I now want to add canonical links to some pages (again, should be in the header). There three cases - no canonical link (most pages) - canonical link based solely on alias (gallery overview pages) - specially generated canonical links not solely based on the alias (gallery image pages). Again, I can do this with a snippet that gets editted every time I add a new gallery page or set of image pages for the sites I manage, but its getting more complicated to maintain! It would be much easier if I could just set a flag in the extra field, and retrieve that flag in a snippet.
The problem here is I don't maintain all the sites that use my gallery code (other than for emergency repair work when the owners mess something up). They have custom management pages (operated from the front-end, not the manager) that create page trees for new users and galleries, populated with the appropriate content and links, I don't fancy trying to write code to load the snippet, edit it, and resave it; I'd much rather just add a flag for the snippet to read.

Others may have other very different ideas that could use an additional field that is simply returned verbatim for user snippets to use, but not used by the system.

I can work round this of course, using extra page templates, but it hopefully gives an idea of why I think it could be useful, and hopefully not too difficult to add.

[Dean]

Being able to add fields within the configuration panel would be good.... so you can add/remove fields on the fly, without the need for hacking the db/core.


Multi-column templates would make use of multiple content fields, for example...

[mikef]

DeanC, on 14 July 2009 - 11:20 PM, said:

Being able to add fields within the configuration panel would be good.... so you can add/remove fields on the fly, without the need for hacking the db/core.


Multi-column templates would make use of multiple content fields, for example...

Yes that would be even better ... but I was trying to keep my request easy to implement so it doesn't get pushed off into coccoon or metamorphosis

[Cris D.]

Sorry guys, but this is beginning to sound like my early attempts to re-create SQL. Is having an additional field going to cause more headaches for support than usability when an additional snippet field can be easily added at the database for seasoned users and a custom data interface created to maintain those relationships? Perhaps this would be overly complex for new users of an already "deep" management navigation.

[PaulD]

Hi,

I take Cris D's point that this might just be problematic. The examples are interesting,

1) A field in which I can define a canonical link
2) A field to flag if a cononical should be used on a page
3) A field to mark if an RSS is available on a page
4) A field to use if a gallery exists
etc etc

All these can be achieved in other ways, but I think that if Etomite had a 'Add a field to the page on the fly', with a default value for all pages, I would definitely use it. In fact I would probably end up abusing it with lots and lots of additional fields.

I like the idea of Etomite being pure and simple. I also think it is more than reasonable to ask developers to add their own tables to look things up in. I think Cris is right to say etomite should not try to recreate SQL too, however, I also think it is reasonable to add a couple of extra custom fields to the page template. IMHO adding just one extra custom field might be just a teaser, and soon people would be saying 'can I have one or two more please'.

I think the answer to 'should eto do it' depends very much on where eto is going, what it plans to be..... and I am not sure where it is going. It is already more than just a CMS. Should it go down the plug and play route a bit more, or should it aim at a more specialised market. I really do not know the answer. I would like the answer to be for eto to aim towards being a lightening fast, minimalist and flexible tool for developers. However for popularities sake it may need to be a bit more plug and play.

In summary, I would use the extra fields and they would come in very handy sometimes. Alternatively I do not want Eto to bloat and become unwieldy or potentially slow. I have had sites that become a pain to maintain because of having to update snippets etc. Although I have always put this down to bad site design on my part (or bad implementation). Often I know how to fix it, but just cant be bothered because of the hassle involved. Ultimately, I don't think eto should pander to my laziness, or lack of foresight or planning, even though it might be useful.

Paul.

PS The first things I would be doing are, flag if page is a product, fields for product name, description, price, stock, weight and supplier. You can see where I would be going with it.....

PPS I might also have a field to use as tags. I currently abuse the keywords and use them as tags. They work really well for that.

[Dean]

Well I'd welcome the idea of the ability to add more fields...


i.e. [*content*] already exists, what about [*content1*] etc, where we can split the templates into multiple columns, different languages and so on...

[mikef]

A lot of interesting comments.

I think PaulD got to the core:

Quote

I think the answer to 'should eto do it' depends very much on where eto is going, what it plans to be..... and I am not sure where it is going.

... and this is something that has been an issue for those not on the development team for a long time now (assuming there is still a development team)

I have to say I don't understand how adding an unused field would complicate things for support and new users ... its just something they can ignore (like I ignore weblinks, for example), and when a new user starts trying out snippet development and finds a need for an extra field it would surely be easier for them in their first steps not to immediately have to deal with creating and managing, updating and querying new tables. Of course everything I mentioned could be managed through a new table or tables, and I likely wouldn't need much help with the queries needed, but for someone new to SQL this would add more to the support burden than one or two fields that can just be ignored ... (To be honest, I suspect the easiest thing for me to do would be to add the fields I want to the document table, and hack the etomite code to provide them along with the other document data, as the data for any page would change only very rarely, but I don't want to go down that route yet.)
And if you are really worried about support overhead, I'd forget about 'Pretty URLs' - whether handled by .htaccess or in the core; they'd cause far more confusion than something unused. (That's one reason I haven't documented what I've done, or released versions of etogal that use it.)

Bloat ... if you don't have unused fields but do add specific fields for various things that people ask for, there'll be more bloat than the unused fields would cause. There may be a lot of requests, for things that not many would use.

[Cris D.]

Just to clarify, I mean that adding an additional field "on the fly" will require many user-choices What type of field is it (BLOB, Datetime, Integer etc what is the default value when created? And least but defiantely not least is what sanitation is done on data entry (this will need to be applicable to the field type). Perhaps a simple int flag that lets you store enum 1 / 0 may be easy but not flexible, perhaps a text field or blob may be flexible but more difficult to manage / maintain and support.

It's just that having worked in the back end of etomite I realise how difficult it is adding these things and although it sounds easy it really isn't- especially to add a one-size fits all solution. Personally, I would rather see the the patches like the "evaluating uncached snippets" and the "save file changes in the file manager" code added to 1.2 before introducing new bugs by extending the managers' capabilities. Don't get me wrong though, if there is an easy solution that I had not considered or if Ralph is willing to do the hours of work required make it happen, I'm all for it- it's just that it is not a trivial exercise.

[mikef]

Cris D., on 18 July 2009 - 11:56 PM, said:

Just to clarify, I mean that adding an additional field "on the fly" will require many user-choices What type of field is it (BLOB, Datetime, Integer etc what is the default value when created?

Ah, but thats not what I suggested - I suggested that a single extra field be created that could be used for anything that a developer wanted. I hadn't thought about blobs and just had in mind a text field, initially blank, and no validation.

Quote

Personally, I would rather see the the patches like the "evaluating uncached snippets" and the "save file changes in the file manager" code added to 1.2 before introducing new bugs by extending the managers' capabilities. Don't get me wrong though, if there is an easy solution that I had not considered or if Ralph is willing to do the hours of work required make it happen, I'm all for it- it's just that it is not a trivial exercise.

Releasing a revision with the stuff that was already fixed at the end of last year (according to the Tracker) would be a step forwards.

[Ralph]

Adding database fields is easy - if you're comfortable with phpMyAdmin... Modifying the manager to include them in data panels can be a nightmare in the current code base... My intention is to make this task simple in the next major release and has been in the design criteria all along... I've done custom data interfaces that would allow an authenticated user to maintain additional document data fields from the front end... This makes full document creation or modification a two step process, however...

[mikef]

Ralph, on 19 July 2009 - 02:08 AM, said:

Adding database fields is easy - if you're comfortable with phpMyAdmin... Modifying the manager to include them in data panels can be a nightmare in the current code base... My intention is to make this task simple in the next major release and has been in the design criteria all along... I've done custom data interfaces that would allow an authenticated user to maintain additional document data fields from the front end... This makes full document creation or modification a two step process, however...

Yes, I've looked at the manager code in the past (during the 0.6.1 RC stages, when looking at how to block robots from the etomite statistics), and decided I didn't want to do anything with the manager UI!
Since the data I'd want to add is static for most of the pages concerned, and I already have code to generate the pages rather than use the manager (all the content in these pages is generated from snippets), actually doing it would be easy. My reluctance is not from any difficulty in making the changes, but because once I do this, any developments to the etogal code would be impossible to release. Once I've touched index.php to modify the fields returned from document pages, I'd probably also modify makeURL to simplify a lot of my other code, this mod being very specific to my sites.