You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@d-haven.org> on 2006/03/28 17:04:06 UTC
How is the cocoon object model set up?
I submitted bug COCOON-1816 because the cocoon object model was not set
up in a way that I expected. It cost hours of lost productivity only to
find out I have to bounce my processing for a static page (with a couple
variable pieces) through a flowscript just to access cocoon.request. To
me that is an example of something that can be fixed to improve the
perceived simplicity of the system. It seems unreasonable to require
Flowscript first for a largely static page--nothing has to be set up, I
just need to get a bit of information from the request object.
I believe the cocoon object model is a great selling point--as long as
it is set up consistently and available to all sitemap components
without forcing one component to be executed before another. Not all
problems require flowscript.
Is the COM strictly tied to the flowscript engine? Is there any way we
can safely and simply extract that out?
Re: How is the cocoon object model set up?
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Berin Loritsch:
> Is the COM strictly tied to the flowscript engine? Is there any
> way we can safely and simply extract that out?
If you are using JXTemplate without FlowScript, try using
${request} directly.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: How is the cocoon object model set up?
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>
>> Berin Loritsch wrote:
>>
>>> I submitted bug COCOON-1816 because the cocoon object model was not
>>> set up in a way that I expected. It cost hours of lost productivity
>>> only to find out I have to bounce my processing for a static page
>>> (with a couple variable pieces) through a flowscript just to access
>>> cocoon.request. To me that is an example of something that can be
>>> fixed to improve the perceived simplicity of the system. It seems
>>> unreasonable to require Flowscript first for a largely static
>>> page--nothing has to be set up, I just need to get a bit of
>>> information from the request object.
>>>
>>> I believe the cocoon object model is a great selling point--as long
>>> as it is set up consistently and available to all sitemap components
>>> without forcing one component to be executed before another. Not all
>>> problems require flowscript.
>>>
>>> Is the COM strictly tied to the flowscript engine? Is there any way
>>> we can safely and simply extract that out?
>>
>>
>> yes, IIRC this is a problem of JXTemplate(Generator|Transformer) and
>> should be solved by the backported template block. I'm sure that
>> Leszek can tell us more about this.
>>
> We also had some discussions about unifying the environment model some
> years ago
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110963086900150&w=2.
> And about "accessors"
> http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/components/accessor/
> that, compared to input modules separates the concerns of accessing an
> environment object and applying e.g. JXPath on it.
>
> But ths work was never finished so there is still a need for a more
> unified way to access "environment" information in Cocoon.
AFAIR the only blocker were the sitemap parameters which could not be
put into object model in clean way. Has anything changed since then?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: How is the cocoon object model set up?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Berin Loritsch wrote:
>> I submitted bug COCOON-1816 because the cocoon object model was not
>> set up in a way that I expected. It cost hours of lost productivity
>> only to find out I have to bounce my processing for a static page
>> (with a couple variable pieces) through a flowscript just to access
>> cocoon.request. To me that is an example of something that can be
>> fixed to improve the perceived simplicity of the system. It seems
>> unreasonable to require Flowscript first for a largely static
>> page--nothing has to be set up, I just need to get a bit of
>> information from the request object.
>>
>> I believe the cocoon object model is a great selling point--as long
>> as it is set up consistently and available to all sitemap components
>> without forcing one component to be executed before another. Not all
>> problems require flowscript.
>>
>> Is the COM strictly tied to the flowscript engine? Is there any way
>> we can safely and simply extract that out?
>
> yes, IIRC this is a problem of JXTemplate(Generator|Transformer) and
> should be solved by the backported template block. I'm sure that
> Leszek can tell us more about this.
>
We also had some discussions about unifying the environment model some
years ago
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110963086900150&w=2.
And about "accessors"
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/components/accessor/
that, compared to input modules separates the concerns of accessing an
environment object and applying e.g. JXPath on it.
But ths work was never finished so there is still a need for a more
unified way to access "environment" information in Cocoon.
/Daniel
Re: How is the cocoon object model set up?
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Berin Loritsch wrote:
>
>> I submitted bug COCOON-1816 because the cocoon object model was not
>> set up in a way that I expected. It cost hours of lost productivity
>> only to find out I have to bounce my processing for a static page
>> (with a couple variable pieces) through a flowscript just to access
>> cocoon.request. To me that is an example of something that can be
>> fixed to improve the perceived simplicity of the system. It seems
>> unreasonable to require Flowscript first for a largely static
>> page--nothing has to be set up, I just need to get a bit of
>> information from the request object.
>>
>> I believe the cocoon object model is a great selling point--as long as
>> it is set up consistently and available to all sitemap components
>> without forcing one component to be executed before another. Not all
>> problems require flowscript.
>>
>> Is the COM strictly tied to the flowscript engine? Is there any way
>> we can safely and simply extract that out?
>
>
> yes, IIRC this is a problem of JXTemplate(Generator|Transformer) and
> should be solved by the backported template block. I'm sure that Leszek
> can tell us more about this.
>
I am sorry not to reply to the list for some weeks now. I am buried
under tons of work.
The backported template block effectively solves the problem described.
The main problem was the inconsistency between direct invocation from
sitemap ( request.something was only available ) and from flowscript (
cocoon.request.something available ).
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: How is the cocoon object model set up?
Posted by Reinhard Poetz <re...@apache.org>.
Berin Loritsch wrote:
> I submitted bug COCOON-1816 because the cocoon object model was not set
> up in a way that I expected. It cost hours of lost productivity only to
> find out I have to bounce my processing for a static page (with a couple
> variable pieces) through a flowscript just to access cocoon.request. To
> me that is an example of something that can be fixed to improve the
> perceived simplicity of the system. It seems unreasonable to require
> Flowscript first for a largely static page--nothing has to be set up, I
> just need to get a bit of information from the request object.
>
> I believe the cocoon object model is a great selling point--as long as
> it is set up consistently and available to all sitemap components
> without forcing one component to be executed before another. Not all
> problems require flowscript.
>
> Is the COM strictly tied to the flowscript engine? Is there any way we
> can safely and simply extract that out?
yes, IIRC this is a problem of JXTemplate(Generator|Transformer) and should be
solved by the backported template block. I'm sure that Leszek can tell us more
about this.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de