118 replies to this topic

[apodigm]

All... apparently not all "0.6" are created equal. I have just been noticed that there are some minor changes between 0.6 RC2 and the final version of 0.6.

Never fear. I have just downloaded the most recent version of 0.6 and updated DocVars so that it is compatible with the final release of 0.6.

.... In this roll-up, I have also included the template manager changes by stebrennan, some tweaks for the weblinks, docvar handling, and updated SQL install script.

So.... if you start with a stock install of 0.6 and then follow the new DocVars contribution, you will be set up in no time with custom document variables - associated with the templates.

Please go to the first post in this message thread to download the new version of DocVars.

[mrpif]

First I want to say I've started to use DocVar and I really like it! Great job!

I'm using it for an agenda section on my site. One of the document variables I need in this section is a date (the event's date, independent from the (un)publication dates), but I'm running across what seems to be a bug in the way dates are retrieved and displayed when one wants to enter a date on a new page or modify an existing one:

1. When setting the date for the first time, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970

2. When modifying a page, whatever the saved date was, the input box show "01-01-1970 01:00:22" ("01:00:22" being the current local time), even though the date was previously saved correctly. Hence, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970.

This problem occurs only for date DocVars, not for the standard date variables (publication / unpublication).

Help!

[apodigm]

mrpif, on Oct 19 2004, 05:20 PM, said:

First I want to say I've started to use DocVar and I really like it! Great job!

1. When setting the date for the first time, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970

Help!

Hmmm.... I don't use the date function much. I'll do some testing on it.

Try this...

In manager/includes/docvars_fields.php around line 39...
comment out this line so it looks like this:

   //            if($field_value=='') $field_value=0;

This will remove the default value of the date field. The default value is being changed to "0" which the calendar popup interprets as January 1st, 1970. (not sure... I didn't write that control.

I noticed that Alex already had some code to set the default value to "" so this should fixe everything for you as far as the default value goes.

let me know if this works.

[mrpif]

apodigm, on Oct 19 2004, 01:53 PM, said:

In manager/includes/docvars_fields.php around line 39...
comment out this line so it looks like this:

   //            if($field_value=='') $field_value=0;

This does not solve the problem. Although, modifying that line this way:

$current_time=time();
if($field_value=='') $field_value=$current_time;

... and replacing the two

$field_value==0

conditions a few lines lower by

$field_value==$current_time

seems like it solves the problem.

But I found there's a deeper problem: if I select a date, say "21-10-2004 15:37:17" in the calendar and then save the page, the date gets stored as "21-10-2004 15:37:17" (i.e. a string) in the etomite_docvars_values table, not as "1098365837" (correct date format, i.e. an integer representing the number of seconds since Jan 1st, 1970).

So when etomite retrieves the date, it doesn't parse it correctly (actually, it just takes the two first digits --the day-- and displays it as the seconds of "1970-01-01 01:00:SS".

I'm searching the actions/dynamic/*.php files for the place where the date gets formatted wrong before it gets sent to MySQL...

[mrpif]

Oops, my mistake, there isn't any problem as long as the Date DocVar hasn't been saved to MySQL. All apologies. So no need to modify includes/docvar_fields.php, it works just fine to select a date the first time.

What needs to be done instead is to insert a condition similar to the one used for the publication date (lines 49-59 in save_content.processor.php), which would convert the date string into a date integer for all date DocVars.

In save_content.processor.php, I inserted the lines:

       }elseif($row['field_type']=='date'){
            $docvar_date = $_POST[$row['field_name']];
            if($docvar_date=="") {
           	 $docvar_date="0";
            } else {
           	 list($d, $m, $Y, $H, $M, $S) = sscanf($docvar_date, "%2d-%2d-%4d %2d:%2d:%2d");
           	 $docvar_date = strtotime("$m/$d/$Y $H:$M:$S");
            }
            $docvars[$row['field_name']] = $docvar_date;

around line 175, before the "else" part of this conditional (starting at line 128)

       if($row['field_type']=='file'){

... and now the date is stored properly in MySQL.

My next problem is: now this date DocVar gets displayed as an integer when I use its [*...*] code. I guess a short snippet will do the conversion...

[mrpif]

OK, this time I think my problem is solved. I created a snippet called [[docvar_date]] that goes like this:

if(!isset($dv)) {
     $mydate = 'No date found';
}else{
     $event_id = $etomite->documentIdentifier;
     $resource = $etomite->getDocVars($event_id, $dv);
     $dvdate = $resource[$dv];
     $mydate = strftime("on %d-%m-%Y at %H:%M", $dvdate);
}
return $mydate;

It's supposed to be used as [[docvar_date?dv=event_date]] where dv specifies the DocVar field name.

This (along with the lines added to save_content.processor.php) solves my problem, although I'd be interested to know if this is considered a "clean" solution.

Thanks for your help.

[apodigm]

Control<>Page, on Oct 21 2004, 07:03 PM, said:

I was playing around about to use this content variables; but for e.g. I use
[*seo_date*] in any part o a document, that's a default variable when i install this extra functions. I doesnt show anything.
Can you explain me? Why? What Am im doing wrong?

Note: I've translated content variables to spanish, as like the Etomite Area.

You probably need to assign the content variable to a template. When I first created the "default" example variables, it didn't have the ability to link a variable to the template.

Basically.... go "edit" the seo_date in the resources section. Make sure you select your template from the drop down list. Then save the variable. .... now you will need to go to your document to edit the actual value of the variable. (If you don't edit the document, there will not be any variable associated with the document.).

Finally.... you need to place the [*seo_date*] somewhere in your template.

[graynorton]

DocVars are great -- they'll be a big help for my project, which requires a fair bit of structured data entry in addition to traditional document editing, all by novice users.

I am planning to create a number of distinct content types, each with a corresponding template. There will be very little overlap between the fields for each type, and some types will have quite a few fields.

Looking at the docvars_values table, I noticed that every DocVar is being saved for every document, regardless of which template is associated with the document. I'm not very knowledgeable when it comes to MySQL optimization, but this seems wasteful to me. Is it?

To remedy this problem (or perhaps non-problem), I just made a one-line mod to save_content.processor.php. Basically, I added a "where" clause to the SQL query on line 122 that gets all of the DocVars, so that it gets only those DocVars associated with the current template. As far as I can tell, this is working, but it seems so obvious that I'm wondering why it wasn't that way already -- is there a reason that I'm not seeing?

Thanks!

[apodigm]

graynorton, on Nov 17 2004, 03:56 AM, said:

To remedy this problem (or perhaps non-problem), I just made a one-line mod to save_content.processor.php. Basically, I added a "where" clause to the SQL query on line 122 that gets all of the DocVars, so that it gets only those DocVars associated with the current template. As far as I can tell, this is working, but it seems so obvious that I'm wondering why it wasn't that way already -- is there a reason that I'm not seeing?

Thanks!

Sounds great. Send me the code or post here.

Originally when I created the contribution, I didn't envision that there would be variables associated with each template. So my original save routine just expected all variables for a document. Now that we have template-based variables, it makes sense to revise the code so that only the variables needed for that template are stored in the database.

I don't want to create code that would skip the saving of a variable (in the event it is blank). This could create PHP errors if you call a variable that didn't exist. hmm... actually, it may be possible to initialize a variable in the event that it didn't get pulled from the database - but was associated with the template. That might slow the parser a bit though....


... but anyway... I agree with you that a content variable should only be stored if it is associated with the template that the document has applied. Post your code and I will update my working copy for the next rollup. There have been some other small bugs that have been found/fixed that might benefit from an update before too long.

Thanks,
JG

[graynorton]

OK, here it is in all of its glory, with a few lines of context:

...
//Added by Apodigm - DocVars
//look up the expected doc vars;  initialize the posted variables if they exist
// Modified by GN
$sql = "select field_name, field_type from $dbase.".$table_prefix."docvars_fields where field_template = $template;"; 
// End GN mod
$rs = mysql_query($sql); 
...

Thanks for the quick response!

[iamrick]

This mod seems just what I was looking for. It's really the only thing that I need to make etomite work the way I want it to. But I'm having a bit of trouble getting it to run correctly. For the installation, I went about these steps:

Version: Etomite 0.6 (Heliades)

SQL
I went and ran the sql query in my database, and it seemed to run fine. The only difference between my other tables in the db, is that the new tables have the prefix etomite_ .

Overwrite Files
Then I went and did an overwrite of the files that was included in the zip file. No problems there.


PROBLEMS
You can have a look that the site is now broken. And I'm also getting these errors when I try to edit/create a document:

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /home/reddc/public_html/manager/actions/dynamic/mutate_content.dynamic.action.php on line 100

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /home/reddc/public_html/manager/actions/dynamic/mutate_content.dynamic.action.php on line 619

Any idea on what the hell went wrong?

Cheers!

[apodigm]

iamrick, on Dec 8 2004, 06:18 AM, said:

I went and ran the sql query in my database, and it seemed to run fine. The only difference between my other tables in the db, is that the new tables have the prefix etomite_ .

This is the problem. When I coded it, I used the standard base (default) install of Etomite, which uses the etomite_ prefix on all db tables.

The easiest way to fix this will be to rename the new docvar tables in your database so that it uses the same prefix as the other tables. Everything should work fine then.

If you run into any other problems, you may do a search on etomite_ in the error files to make sure that I didn't hardcode the db table name. I tried to keep consistent and use the global "prefix" variable, but I may have missed a line in my haste.

JG

[iamrick]

Ah, so simple - thanks JG. Also, one more thing... should I add this code to it to make the system a bit smarter? Or just leave it out...

graynorton, on Nov 17 2004, 08:50 AM, said:

OK, here it is in all of its glory, with a few lines of context:

...
//Added by Apodigm - DocVars
//look up the expected doc vars;  initialize the posted variables if they exist
// Modified by GN
$sql = "select field_name, field_type from $dbase.".$table_prefix."docvars_fields where field_template = $template;"; 
// End GN mod
$rs = mysql_query($sql); 
...

Thanks for the quick response!

Thanks again

[apodigm]

iamrick, on Dec 8 2004, 12:32 PM, said:

Ah, so simple - thanks JG. Also, one more thing... should I add this code to it to make the system a bit smarter? Or just leave it out...
Thanks again

It certainly would not hurt if you added it. If you don't make the change it is not a big deal for most websites since you are only using one or two main templates in the website. But if you have multiple templates (and multiple docvars), then this extra line of code will help to keep the size of your database down.

I've planned to post a roll-up of all the changes/bug fixes, but this is the only code I've added to my development files. If you catch some new items, let me know and I can work on a new rolled up release with everything fixed/included.

Thanks,
John Guerra
Apodigm, Inc.

[apodigm]

eko40, on Dec 8 2004, 02:15 PM, said:

I've not yet installed this mod as I've no "visual" clue about what I can achieve with it, indeed a newbie and non-programmer problem. It would be useful if kind of example site or some screenprints were provided. I also wonder why the mod-download doesn't include the  improvement yet as it doesn't seem to "harm" to include the one improvement. By the way etomite is great in its simplicity and more importantly flexibility, but then posters on this forum seem to be very aware of that. I'm only a bit concerned about development cycles and userbase.

Screenshots might be nice. If anyone would like to post, that would be cool. Otherwise I will look at posting something this weekend. The truth is... if you have a need for something like DocVars you would already know what it does. If you don't know how you would use it, then you probably don't need to install it. It is really just an extension of Etomite that gives a little more flexibility to the document concept. .... like I said... you probably shouldn't use it unless there is a specific need for it.

As far as the mod-download concept, I have not seen that complete. I think that Alex included it in 06 build, but it doesn't seem to be well documented - or working for that matter. Even if it was, this contribution would probably not fit there anyway. We are modifying some of the base code that is in the main Etomite parser and I dont think the mod-download was intended to allow that anyway. DocVars is fairly easy to install, but I agree it is not as easy as the install scripts that Alex wrote for the base etomite installer.

... and a little off topic for this thread... but I agree that Etomite is powerful for it's simplicity and flexibility. Another one that is starting to look a lot like Etomite with similar simplicity is CMS Made Simple (http://cmsmadesimple.org/). It looks like it has most of the same features except that I don't think it has PHP code concept (like Etomite's snippets). The snippets is really what makes Etomite the clear choice. But for all newbies that want to compare multiple CMSs and find one that they prefer, here is one of the better resources I have found:
http://test.opensourcecms.com/

... anyway... DocVars is the topic for this thread. If you do decide to try and install it, you can post your experiences/questions in this message thread for support. (I can't guarantee I will respond right away, but I usually try to get back in a day or two.)

JG
Apodigm, Inc.