[campsite-dev] Re: smarty discussion
  • 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
    > --------------------------------------------------------
    >
    >
  • 3 Comments sorted by
  • 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
    > --------------------------------------------------------
    >
    >
  • Can somebody tell me if there is central setting to disable the usage of apc cache mechanism in campsite admin?

    Thanks,
    Sebastian
  • 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