[apodigm]

Ok, folks.

This is not the full blown "content templates" that Alex has planned, but it satisfies my needs and I hope you enjoy it.

Basically, we use Etomite as a CMS for websites where a non-technical person could be managing the content documents. We have found that the [*title*], [*description*], and [*content*] was just too limiting for what we needed. We wanted the ability to add extra "fields" that the CMS manager could associate with each document. Although this can be accomplished with snippets, it was not very elegant or user friendly as we wanted for our non-technical customers.

I have borrowed heavily from Alex's code, as well as some code from another open source CMS, and a lot of my own code, to prepare this contribution. Once installed, it will allow you to create the variables that you want associated with the documents. At this time, it is limited to only a "global" list of variables, so it is not as flexible as a "content template" that might be created and applied to the documents (so that the extra variables are different depending on which type of content template you have applied). But for now, this seems to be good enough to hold us over.

The variables (aka fields) that you can add to the documents include:
- radio selection
- checkbox
- select dropdown
- select box (including support for multiple options)
- text (simple one line field)
- textarea (plain text textarea)
- htmlarea (htmlarea applied to the textarea - assuming you have htmlarea enabled)
- file (including file upload, preview, delete, and "clear" functions)
- date (which uses the same calendar as the publish/unpublish feature
- text with specific requirements: URL, Price, Email

I have written the code to embed this in the IE dropdown menu layout so it is included with the resources menu. It is also located in the "Manage Resouces" page if you are using the other layout option.

After you have it installed, you can call the extra document variables, just like you would use the other content variables in your template, snippet, chunk. [*my_extra_variable*]

This was written based on the 0.6 (edit) FINAL release and I have provided my modified files if you just want to diff with your install.

I've done quite a bit of testing and debugging, but let me know if you find problems with it. web_at_apodigm.com

****EDIT****
I'm posting a new version of DocVars (aka Document Content Variables) here soon. It includes a roll up of all the changes that have been posted in this forum up to this point. It is also compatible with the final release of Etomite 0.6. It will be posted soon.

This also includes contributions from stebrennan:
Variables associated with the templates
(so that "content variables" are associated with each display template... creating something more like content templates)

Also, includes minor bugs and fixes to some of the items found in this forum...

************

Attached File(s)

•  docvars06.zip (63.98K)
  Number of downloads: 686

This post has been edited by apodigm: 07 October 2004 - 05:54 AM

[newcomer]

I played with this a bit and liked it. One question that came to mind would be the order in which the content variables show up during editing.
For example, I created one called abstract and one called conclusion.
Would like the abstract to appear first, followed by the regular content of the page and the conclusion so that when someone is creating a page, the flow would be obvious. I know I can alter the templates to control presentation but I am also trying to make it as easy as possible for the content maintainers to easily put in the right content in the system.

Once again, great modification. Just what the doctor ordered
Thanks
newcomer

[apodigm]

newcomer, on Sep 8 2004, 01:58 AM, said:

One question that came to mind would be the order in which the content variables show up during editing.

Certainly. This is also already built in. (although not very elegantly yet).

When you create/edit the additional document variables, there is a place where you can specify "rank". The rank is basically going to determine the order in which the document variables are displayed to the content page editor. (displayed in ascending order).

So the item you want displayed first, put a rank of "1". Then the item you want displayed second, put a rank of "2". You may want to leave some extra numbers in the middle for later additions. Basically it is just a numerical field.

When you view the resource manager page, the variables are orded by rank, so you can see the order they will be displayed (and edit as necessary). I believe that if you leave the rank option blank, it will assume they are all the same rank and will just display in the order that mysql returns them (which is usually also the order you have entered them).

[newcomer]

I noticed that part of the content variable. I guess what I was asking was interlacing it with the current document entry section so some variables will appear above it, ranked as you mentioned and some will rank below it.
So what you will see is
Content variables (section - TOP)
Items rank accordingly

Document Content (section - default by etomite)

Content variables (section - BOTTOM)
Items ranked accordingly

Following the above, in my scenario, you will have
Content Variables
Abstract

Document Content

Content Variables
Conclusion.

Just thinking out loud, this would probably require another field labelled position with entries of top/botton along with the rank field

Thanks for your quick response
newcomer

[apodigm]

I see what you mean.

I originally started with this trying to minimize the code changes to the existing Etomite files. But as I got into it, I modified more than I would have wanted to.

I think we could probably do something like that "position" thing and specify areas in the editor. But I would probably wait to see what Alex's roadmap for "content templates" will be. It might be easiest if we just remove the "content" value from the existing editor and just add is as a variable.

[newcomer]

I agree that have Document content become just another content variable would be the ideal way to go. In this scenario, it could be the default content variable provided by the system with modifiable rank

It would be interesting to see how Alex tackles this problem

This system is just getting better and better due it its infinite flexibility

Thanks again for the modifications. I am using it and liking it with each passing minute

Thanks
newcomer

[stebrennan]

Hi,

Just like to say, great little modification this.

I was having a play around with it last night and have made a few changes that may be of interest.

- I have assigned content variables to individual templates (so different templates can have different content variables)

- I have also moved the content variables section (when editing a document) below the main content area - dunno seemed to make more sense to me?

- I tweaked it so that form fields line up with the other standard document form fields.

Seeing as I only did this in about an hour in the evening, it may not be perfect, but so far it seems to work OK

If anyone is interested, give me a shout.

[apodigm]

stebrennan, on Sep 8 2004, 02:01 PM, said:

- I have assigned content variables to individual templates (so different templates can have different content variables)

- I have also moved the content variables section (when editing a document) below the main content area - dunno seemed to make more sense to me?

- I tweaked it so that form fields line up with the other standard document form fields.

I would be interested in this. I like newcomer's idea of allowing "content" to become another variable so that it can be placed anywhere in the list of variables. The reason I put the extra variables first is because of the way we intend to use the document variables for our customer (mostly header and left column stuff), but I understand there are some times when you would want to have a variable listed below the main content area.

In order to accomplish this, we can move [*content*] as one of the variables. At the same time, I think we should add a question where we define the variable so that we can adjust the size of the htmlarea associated with each variable.

At the same time, I would love to extend the document variables so that they can be asociated with the dispaly template. That was my original intent. My only problem was this.... when you create a new document, it will just use the first template available (which means the variables that get loaded in the document editor would not be correct). In order to have "content templates" associated with the theme "template", we would need to add an extra step in the New Document process where you specify the template BEFORE you get dropped into the editor. which raises the concern about what happens when a customer changes the template associated with an existing document?

Alex,
Do you have some thoughts on this? You were going to include content templates in 07, but if we can help get some of this ready, it looks like we have an opportunity here.

[stebrennan]

apodigm, on Sep 8 2004, 02:19 PM, said:

At the same time, I would love to extend the document variables so that they can be asociated with the dispaly template.  That was my original intent.  My only problem was this.... when you create a new document, it will just use the first template available (which means the variables that get loaded in the document editor would not be correct). In order to have "content templates" associated with the theme "template", we would need to add an extra step in the New Document process where you specify the template BEFORE you get dropped into the editor. which raises the concern about what happens when a customer changes the template associated with an existing document?

Alex,
Do you have some thoughts on this?  You were going to include content templates in 07, but if we can help get some of this ready, it looks like we have an opportunity here.

Yep very true - such is the way of the fudge :betterwink:

My intention was to finish it off so that if you change a template, you are warned that you will loose all unsaved data. Not ideal granted but as I don't have much time at the moment to take it any further, that seems like a fair compromise.

When I've double tested the code, I post the amended scripts here.

[summean]

Very cool snippet/modification... What are you guys using the content variables for though? I was trying to think of some times where it may be applicable...

[stebrennan]

summean, on Sep 8 2004, 03:54 PM, said:

Very cool snippet/modification...  What are you guys using the content variables for though?  I was trying to think of some times where it may be applicable...

It can be used for all sorts of things e.g. to store extra product information (effectively each product is a document with extra additional product related fields such as product code etc. in separate fields), additional newstory fields, case studies, documents where content is split across different areas of a template e.g. 2 content areas - a middle or main content section and side content section etc....

[apodigm]

Lots of ways to use this....


Here is the original scenario why we wanted this...

We are integrating phpList with Etomite so that as a content administrator uploads content for a page, it can also be used in an outgoing subscriber newsletter. The issue we had was that phpList has the ability to send either Plain text emails or HTML emails, depending on what the end customer selects when the subscribe to the newsletter. Rather than have our content admin enter the same information in Etomite, and then again in phpList, we are modifying phpList so that it will pull the content from the Etomite database. But alas, we only had the one "content" variable and couldn't add the "plain text" easily. (Remember, we have non-technical users here so as simple as we can make it!)

After we started playing with that, we realized that there is often a part of a page that the end user wants to modify. In our case, there is a "header" welcome statement that is associated with the content page, but it is embedded in our on-the-fly flash script. We are using ming to generate the flash files based on the content variable, and then storing the file for later use. This is a very fast way to create unique headers for each content page - with a content-centric flash-enabled quote. It would not be practical to build a different theme template for each version we have. (Like I said, this could be done using snippets, but it would not be user friendly for the normal joe.)

In another scenario, we wanted to implement LiveHelp and use the feature they have where the livehelp can direct to a specific department, depending on what page of the website they are located. This is done with a department code that is attached to the livehelp script and is different for each page. Using a content variable, we can allow the content administrator to specify which LiveHelp department to associate with each content page.

Another application we are working on is a Search Engine Optimization recording for each content page. So we have variables like optimization date, targeted keywords, targeted search engine, search engine submission date, next scheduled optimization date, etc. We can associated the process flow variables to the document. Of course, the SEO administrator would have an extra set of admin pages (elsewhere) where they can view/modify as needed.

wheh... if that wasn't enough, I think what most people that are using this script really want is the ability to specify content for different areas of thier visual template. I would think of this more like content areas. So your template would have [*content_left*] and [*content_footer*], etc. This way your content administrator could put unique information for the content areas of each document, without having to jack with the template.

[apodigm]

um... just thought of one more...

You can also add a "file" content variable, in case you want to associate a file with the content. For example, this could be an audio file for background music, or it could be an image that represents the content page.

Since the image file can be stored as a separate content variable in the database, you could display it in the search results, product catalog, sitemap, etc. The way Etomite ships today, you could embed an image in the content, but you would not be able to separate the image from the content.

Also note... since the content variables are also associated with the document itself, you can use them in the snippet code, just as you would call the content variable.

[stebrennan]

--------