My suggestion is not to let our template designers to be lazy. I
believe if you define strict rules, you will maintain easier code and
it is easier to read the template code. Considering the namespace,
the article fields can use "whole capital" words, so the idea to use
underscores is so far best.
However I have no idea why you differ article->_CUSTOM_ fields from
the standard article name. In my opinion the best readable would be
something like:
$campsite->article->field->field_name

Ondra

On 6.8.2007, at 15:37, Mugur Rus wrote:

> Hi Micz, Hi Holman,
>
> Regarding the object properties (see point 2 below), actually we
> don't have variable named properties.
>
> $campsite->article->type->fastnews->body doesn't have any variable
> part. Once the article types are defined, fastnews->body is FIXED.
> Also, every other property in the template language has a fixed
> name. E.g:
> - $campsite->issue->name
> - $campsite->section->number
> - $campsite->topic->name
> etc.
>
> The only properties that are 'pseudovariable' are the article
> custom properties. But they don't change every day or every week also.
>
> To me having the whole template language defined in the following
> way, as an example:
> - $campsite->ISSUE->NAME
> - $campsite->SECTION->NUMBER
> - $campsite->TOPIC->NAME
> in order to be able to specify that ONLY in the article object (one
> object in about 20) some fields are custom specified doesn't make
> sense.
>
> What makes sense to me is to underscore the fact that a certain
> field is custom defined in a certain way, e.g.:
>
> - $campsite->article->_TYPE_->fastnews->author (displays the author
> field from articles of type fastnews)
> - $campsite->article->_CUSTOM_->author (displays the author field
> from any article type that has a field author)
>
> although $campsite->article->author should work too, for the people
> that are too lazy to write an extra word.
>
> And talking about being lazy, we could create an alias $cs that
> points to the same variable $campsite and each one could use the
> one he/she prefers. Although I don't know if it's a good idea to
> have duplicate names for the same variable. We can negotiate on
> using $cs or $campsite and maybe we should continue this discution
> on campsite-dev.
>
> Mugur
>
> On 7/27/07, Micz Flor wrote:
> hi mugur, holman,
>
> i just mail this to you, before i forget.
>
> from the templating point of view, i would
>
> 1. shorten the $campsite to $cs because i have to type this all the
> time
>
> 2. what we discussed, make clear in the lingo what is method and what
> is variable
>
> instead of $cs->article->type->fastnews->body
>
> either
>
> $cs->ARTICLE->TYPE->fastnews->body
> (advantage: short, disadvantage: difficult to type and possibly
> difficult to catch in your customised functions)
>
> or
>
> $cs->#article->#type->fastnews->body
> $cs->_article->_type->fastnews->body
> $cs->!article->!type->fastnews->body
>
> something like this - we will need to discuss this
>
> Micz Flor - micz@mi.cz
>
> content and media development http://mi.cz
> --------------------------------------------------------
> http://www.campware.org -- http://www.suemi.de
> http://www.redaktionundalltag.de
> --------------------------------------------------------
>
>

Of course,

You can do that by setting to false the member variable m_useCache in
the DatabaseObject.php class file.

there is a $Campsite['ENABLE_CACHE'] option in the configuration.php
file but it is not used at all.



On 8/7/07, Sebastian Goebel wrote:
> Can somebody tell me if there is central setting to disable the usage of apc cache mechanism in campsite admin?
>
> Thanks,
> Sebastian
>
>


--
/holman