Re: Why changes in triggerEvent? AND headScript

Yes, I had this possibility in mind, but we have 20 Nodes and more. Ok -
it would not be much work, but some objects more which make the whole
thing more difficult to overview. It is just, because I can not see the
reason for disabling acquisition in an acquisitioning environment.
Can anyone please explain this to me?

Regards
Peter Zechmeister



Am Donnerstag, den 27.09.2007, 12:12 +0200 schrieb Richard Bendit:
> Hello Mr. Zechmeister,
> 
> why not putting on every home-folder a "headScript" Method but inside
> something like:
> 
> <dtml-var yourcodeObject>
> 
> Then put another Method in the hierachicsl tree about => with the id
> "yourcodeObject" and inside that your new Scripts. 
> So then you create a central area to manage all headScripts in one
> area.
> 
> Regards
> 
> Richard Bendit
> 
> 
> 
> 
> 
> 2007/9/27, Peter Zechmeister <[email protected]>:
>         Its the same again but in this case with the headScript
>         functionality: 
>         headScript lies in dtml/zms/headscript.dtml
>         It is responsible for the JavaScript-loading lines in the
>         HTML-header
>         and it can be automatically replaced by a script with the id
>         "headScript" in the ZMS-homefolder in ZMI. The quirk here is,
>         that it
>         has to be located exactly into the homefolder, not in the
>         hierarchy
>         above. Acquisition is not possible.
>         We want to implement our own headScript, but we have a lot of
>         ZMS-Nodes
>         in a hierarchical tree, where the templates all lie on top of
>         the tree
>         and get fetched from the nodes by acquisiton. Due to the
>         acquisition-unfriendly behaviour of headScript, we have to put
>         a copy of
>         our headScript to each node. 
>         This is thwarting our template architecture and also what
>         zms-publishing
>         is propagating for big sites.
>         Its the same as with the onChangeObjEvt funktionality (see
>         below).
>         Why is that in this way? Can this get changed to be more
>         acquisiton-friendly?
>         
>         Regards
>         Peter Zechmeister, WebOffice-JKU
>         
>         Am Montag, den 13.08.2007, 12:55 +0200 schrieb Peter
>         Zechmeister:
>         > Hi,
>         > 
>         > we have got some troubles, because there have been some
>         changes in
>         > _versionsmanager since one of the latest ZMS-Versions which
>         affect our
>         > architecture.
>         > 
>         > The funcion "triggerEvent" does look only into homefolder
>         for
>         > eventscripts any more
>         > 
>         > for ob_id in self.getHome().objectIds():
>         > 
>         > In former versions it did acquisition from above 
>         > 
>         > if hasattr(self,name):
>         > 
>         > This is bad, because we have onChangeObjEvt - logic at one
>         central
>         > place
>         > above in the tree. Now we have either to patch the ZMS or to
>         put the
>         > onChangeObjEvt script to each ZMS-Home folder.
>         > 
>         > What was the reason for those changes?
>         > 
>         > Regards
>         > Peter Zechmeister, WebOffice-JKU
>         > 
>         > -- 
>         > Knight Rider was a very stupid American television show. Its
>         only
>         > redeeming social value was, of course, the blinking lights.
>         > http://www.joedog.org/JoeDog/Wackyd
>         > 
>         > 
>         > 
>         > 
>         > 
>         -- 
>         It's struck me that the desire of people to market the RUP as
>         the single
>         process led to a result where people can do just about
>         anything and call
>         it RUP - resulting in RUP being a meaningless phrase.
>         (http://www.martinfowler.com/articles/newMethodology.html)
>         
>         
>         
>         
> 
> 
> 
> -- 
> bendit consulting
> Inh.: Richard Bendit
> Friedrich-Ebert-Str. 26
> 61130 Nidderau
> 
> Tel. 06187-936987
> Fax. 06187-936988
> 
> USt-IdNr.: DE174037709
> 
> http://www.bendit.de
> 
> 
>  
-- 
It's struck me that the desire of people to market the RUP as the single
process led to a result where people can do just about anything and call
it RUP - resulting in RUP being a meaningless phrase.
(http://www.martinfowler.com/articles/newMethodology.html)