You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by oceatoon <t....@systheo.com> on 2005/01/21 18:53:28 UTC
WishFull thinking JX and SessionContext Authentication
This is wishfull thinking and probably no news to those refactoring JX. But
access to the session context object like the session-context input module
would be great (like for example with the authentication context). I have
found other post asking about and for this sort of functionality. it would
smoothen quite a bit the access to such inportant elements as the ones in
session-context (like authentication data).
Regards
Tibor
Re: WishFull thinking JX and SessionContext Authentication
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>
>> don't we have a pluggable object model ? :))
>>
>> function doIt() {
>> var objectModel = {};
>>
>> objectModel.pluggedIn1 = entityFromDatabase();
>> objectModel.pluggedIn2 = request.getParameter( "skin" );
>>
>> cocoon.sendPage( "view/myview.jx", objectModel );
>> }
>>
>> Other data that is not directly available from flow (like
>> authentication context can be accessed with input modules that are
>> already available).
>>
> And this is exactly my problem :)
> With this approach you have to get all the data for each
> cocoon.sendPage() and store it somewhere. If you use a lot of flow this
> creates a maintenance nightmare. Of course you could provide your own
> sendPage() function that does all the work, but it's not a nice way of
> doing it.
>
> So why not defining plugins for the object model somewhere and as soon
> as you use them in your template they are queried to provide information.
>
> Carsten
>
If so I would go even further:
I had a publishing project where EVERY bizData had to have a lot of
entities and configuration variables stored. So each time you prepared
data for the view you had to do:
var bizData = prepareBizData();
bizData.additional = "sth";
cocoon.sendPage( "view.jx", bizData );
prepareBizData() mostly fetched data via hibernate and performed very
easy condition checking.
It would be nice if we could introduce some kind of data "aspects" so
every objectModel gets appropriate entries without explicitly creating
them every time. My usecase was simple but we can dig more ie. every
user management page has to have acces to user roles list while every
other page needs the currently logged in user.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: WishFull thinking JX and SessionContext Authentication
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
> don't we have a pluggable object model ? :))
>
> function doIt() {
> var objectModel = {};
>
> objectModel.pluggedIn1 = entityFromDatabase();
> objectModel.pluggedIn2 = request.getParameter( "skin" );
>
> cocoon.sendPage( "view/myview.jx", objectModel );
> }
>
> Other data that is not directly available from flow (like authentication
> context can be accessed with input modules that are already available).
>
And this is exactly my problem :)
With this approach you have to get all the data for each
cocoon.sendPage() and store it somewhere. If you use a lot of flow this
creates a maintenance nightmare. Of course you could provide your own
sendPage() function that does all the work, but it's not a nice way of
doing it.
So why not defining plugins for the object model somewhere and as soon
as you use them in your template they are queried to provide information.
Carsten
Re: FOM & input modules
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, 25 Jan 2005 23:58:41 +0100, Sylvain Wallez <sy...@apache.org> wrote:
<snip/>
> I also would like to insist on the fact that FOM (flow object model) is
> nothing more than OM (object model) that we have everywhere in Cocoon,
> but rewrapped as JS objects. So we should better concentrate on the OM
> itself and let its JS counterpart follow its evolutions.
+1 Yes, please.
--
Peter Hunsberger
Re: Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Thank you, that's much clearer than my explanation (though I meant the
> same ;-)
LOL!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Reinhard Poetz wrote:
>>
>>
>
>>>> After some experiments with the new compiling classloader stuff, I
>>>> personally don't feel a need for a scripting action solution. But
>>>> this highly depends on your skills.
>>>
>>>
>>>
>>>
>>> Interesting, do you mean that you write ordinary actions and use the
>>> compiling classloader on them?
>>
>>
>>
>> I tried it and it worked for me. Currently, *you* have to make sure
>> that the sitemap reloads (e.g. adding a space character) but if I
>> understood Sylvain's mail to his "lazy mode" implementation correctly,
>> this will help to get rid of this (ugly) workaround.
>
>
>
> Ahem, no: the lazy mode only loads (and therefore compiles) components
> the first time they are looked up in the service manager. That means
> that currently you have to "touch" the sitemap in order for classes to
> be reloaded.
>
> But the actual purpose of the lazy mode is not only fast startup time,
> but also fast *reload* time: the idea is that when a source file is
> changed, Cocoon is restarted in the same way as a ?cocoon-reload=true,
> therefore recompiling everything that needs to be recompiled and
> garbaging all instances of the previous versions of recompiled classes.
>
> But that reloading isn't there yet.
Thank you, that's much clearer than my explanation (though I meant the same ;-)
--
Reinhard
Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>
>>> After some experiments with the new compiling classloader stuff, I
>>> personally don't feel a need for a scripting action solution. But
>>> this highly depends on your skills.
>>
>>
>>
>> Interesting, do you mean that you write ordinary actions and use the
>> compiling classloader on them?
>
>
> I tried it and it worked for me. Currently, *you* have to make sure
> that the sitemap reloads (e.g. adding a space character) but if I
> understood Sylvain's mail to his "lazy mode" implementation correctly,
> this will help to get rid of this (ugly) workaround.
Ahem, no: the lazy mode only loads (and therefore compiles) components
the first time they are looked up in the service manager. That means
that currently you have to "touch" the sitemap in order for classes to
be reloaded.
But the actual purpose of the lazy mode is not only fast startup time,
but also fast *reload* time: the idea is that when a source file is
changed, Cocoon is restarted in the same way as a ?cocoon-reload=true,
therefore recompiling everything that needs to be recompiled and
garbaging all instances of the previous versions of recompiled classes.
But that reloading isn't there yet.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>
> <snip/>
>
>>> If you need the above i18n stuff in all your pipelines you could just
>>> call a (flow)script action without any match criterion in the
>>> begining of your pipeline and let it calculate the locale and put it
>>> in a context variable where it is visible in the rest of the pipelines.
>>
>>
>> After some experiments with the new compiling classloader stuff, I
>> personally don't feel a need for a scripting action solution. But this
>> highly depends on your skills.
>
>
> Interesting, do you mean that you write ordinary actions and use the
> compiling classloader on them?
I tried it and it worked for me. Currently, *you* have to make sure that the
sitemap reloads (e.g. adding a space character) but if I understood Sylvain's
mail to his "lazy mode" implementation correctly, this will help to get rid of
this (ugly) workaround.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> If you need the above i18n stuff in all your pipelines you could just
>> call a (flow)script action without any match criterion in the begining
>> of your pipeline and let it calculate the locale and put it in a
>> context variable where it is visible in the rest of the pipelines.
>
> After some experiments with the new compiling classloader stuff, I
> personally don't feel a need for a scripting action solution. But this
> highly depends on your skills.
Interesting, do you mean that you write ordinary actions and use the
compiling classloader on them?
/Daniel
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>>
>>>>> Please note that I'm not suggesting to remove the current input
>>>>> modules. This is all about making Cocoon more coherent, not about
>>>>> introducing back incompability. If we find a good way to replace
>>>>> input modules I would suggest that we move them from core to an
>>>>> input module block so that they become optional.
>>>>>
>>>>> WDYT?
>>>>
>>>>
>>>> Having only one input module that uses a Cocoon wide object model is
>>>> IMO a good idea. We should go through the list of all input modules
>>>> and look where it makes sense to extend the object model.
>>>
>>>
>>> I wrote the slightly commented list of input modules that you cutted
>>> away from my post in the hope of geting some input about that. I use
>>> modules that overlaps with FOM in nearly all of my sitemaps so I
>>> don't have much opinion about the more exotic modules.
>>>
>>> The things that I need that not is part of FOM is some type of
>>> handling of global or sitemap specific data corresponding to e.g.,
>>> DefaultsModule or GlobalInputModule. But it is rather the handling of
>>> application parameters than the actual input module solution that I
>>> need.
>>>
>>> Also I have used the BaseLinkModule and some own module for URL
>>> rewriting purposes.
>>>
>>> Both application parameters and better sitemap related URL handling
>>> could be part of the Context object IMO.
>>>
>>>> Creating a modules block that contains all existing input modules
>>>> for backwards-compatibility sounds good to me too.
>>>>
>>>> One question remains: Should it be allowed to add your
>>>> project-specific extenstions to the object model? e.g. I like to use
>>>> chained input modules (i18n issues) or my own constants input modules.
>>>
>>>
>>>
>>>
>>> Could you explain your use case a little bit more.
>>
>>
>>
>> Something like this:
>> <component-instance name="l"
>> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
>> logger="core.modules.input">
>> <!-- first try the 'locale' request param -->
>> <input-module name="request-param"/>
>> <!-- next the session attribute -->
>> <input-module name="session-attr"/>
>> <!-- next try the request locale attribute -->
>> <input-module name="request-language"/>
>> <!-- finally use a default value -->
>> <input-module name="settings"/>
>> </component-instance>
>>
>> This is useful to determine the language of my application but needs
>> to be configurable. Don't know if such a chain module should be part
>> of the object model, but why not.
>
>
> Why not? Because chain modules and the rest of the meta modules IMO
> sucks from readability POV. Without the comments the above snippet would
> have said nothing to me. I would guess that if you had written the above
> code in terms of flowscript it would have been much easier to see what
> happens.
good idea! I haven't thought much about this yet, but I think you're right. (I
was just a user who found a solution for this problem :-) )
> If you need the above i18n stuff in all your pipelines you could just
> call a (flow)script action without any match criterion in the begining
> of your pipeline and let it calculate the locale and put it in a context
> variable where it is visible in the rest of the pipelines.
After some experiments with the new compiling classloader stuff, I personally
don't feel a need for a scripting action solution. But this highly depends on
your skills.
>
> To me that is less magic than having a XML based semi program language
> in your configuration.
>
> The original idea with input modules, giving pluggable access to
> environment properties was a good idea IMO. Even if the inteface with
> all the configuration parameters smells FS to me. But then a small
> program language is build on top of that in terms of the meta modules
> with more or less obscure programming constructs.
>
> IMO we should try to give this a fresh look and try to get rid of the
> need to use meta modules. So I don't feel any entusiasm for pluggin in
> modules in the object model.
>
> From the discussion this far my conclusion is that we need to
> strengthen the context model with same kind of application global
> parameters, better info for URL rewriting and also that we need
> (flow)script actions for an easy way to put application specific data in
> the object model.
ok, sounds reasonable
> But I have not yet seen any use cases that convinces me about the
> necesity in pluging input modules into the object model.
>
> Maybe our anti FS task force have some wise words to add ;)
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>> Daniel Fagerstrom wrote:
>>>>
>>>> Please note that I'm not suggesting to remove the current input
>>>> modules. This is all about making Cocoon more coherent, not about
>>>> introducing back incompability. If we find a good way to replace
>>>> input modules I would suggest that we move them from core to an
>>>> input module block so that they become optional.
>>>>
>>>> WDYT?
>>>
>>> Having only one input module that uses a Cocoon wide object model is
>>> IMO a good idea. We should go through the list of all input modules
>>> and look where it makes sense to extend the object model.
>>
>> I wrote the slightly commented list of input modules that you cutted
>> away from my post in the hope of geting some input about that. I use
>> modules that overlaps with FOM in nearly all of my sitemaps so I don't
>> have much opinion about the more exotic modules.
>>
>> The things that I need that not is part of FOM is some type of
>> handling of global or sitemap specific data corresponding to e.g.,
>> DefaultsModule or GlobalInputModule. But it is rather the handling of
>> application parameters than the actual input module solution that I need.
>>
>> Also I have used the BaseLinkModule and some own module for URL
>> rewriting purposes.
>>
>> Both application parameters and better sitemap related URL handling
>> could be part of the Context object IMO.
>>
>>> Creating a modules block that contains all existing input modules for
>>> backwards-compatibility sounds good to me too.
>>>
>>> One question remains: Should it be allowed to add your
>>> project-specific extenstions to the object model? e.g. I like to use
>>> chained input modules (i18n issues) or my own constants input modules.
>>
>>
>>
>> Could you explain your use case a little bit more.
>
>
> Something like this:
> <component-instance name="l"
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input">
> <!-- first try the 'locale' request param -->
> <input-module name="request-param"/>
> <!-- next the session attribute -->
> <input-module name="session-attr"/>
> <!-- next try the request locale attribute -->
> <input-module name="request-language"/>
> <!-- finally use a default value -->
> <input-module name="settings"/>
> </component-instance>
>
> This is useful to determine the language of my application but needs to
> be configurable. Don't know if such a chain module should be part of the
> object model, but why not.
Why not? Because chain modules and the rest of the meta modules IMO
sucks from readability POV. Without the comments the above snippet would
have said nothing to me. I would guess that if you had written the above
code in terms of flowscript it would have been much easier to see what
happens.
If you need the above i18n stuff in all your pipelines you could just
call a (flow)script action without any match criterion in the begining
of your pipeline and let it calculate the locale and put it in a context
variable where it is visible in the rest of the pipelines.
To me that is less magic than having a XML based semi program language
in your configuration.
The original idea with input modules, giving pluggable access to
environment properties was a good idea IMO. Even if the inteface with
all the configuration parameters smells FS to me. But then a small
program language is build on top of that in terms of the meta modules
with more or less obscure programming constructs.
IMO we should try to give this a fresh look and try to get rid of the
need to use meta modules. So I don't feel any entusiasm for pluggin in
modules in the object model.
From the discussion this far my conclusion is that we need to
strengthen the context model with same kind of application global
parameters, better info for URL rewriting and also that we need
(flow)script actions for an easy way to put application specific data in
the object model.
But I have not yet seen any use cases that convinces me about the
necesity in pluging input modules into the object model.
Maybe our anti FS task force have some wise words to add ;)
/Daniel
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>>
>>> Please note that I'm not suggesting to remove the current input
>>> modules. This is all about making Cocoon more coherent, not about
>>> introducing back incompability. If we find a good way to replace
>>> input modules I would suggest that we move them from core to an input
>>> module block so that they become optional.
>>>
>>> WDYT?
>>
>>
>>
>> Having only one input module that uses a Cocoon wide object model is
>> IMO a good idea. We should go through the list of all input modules
>> and look where it makes sense to extend the object model.
>
>
> I wrote the slightly commented list of input modules that you cutted
> away from my post in the hope of geting some input about that. I use
> modules that overlaps with FOM in nearly all of my sitemaps so I don't
> have much opinion about the more exotic modules.
>
> The things that I need that not is part of FOM is some type of handling
> of global or sitemap specific data corresponding to e.g., DefaultsModule
> or GlobalInputModule. But it is rather the handling of application
> parameters than the actual input module solution that I need.
>
> Also I have used the BaseLinkModule and some own module for URL
> rewriting purposes.
>
> Both application parameters and better sitemap related URL handling
> could be part of the Context object IMO.
>
>> Creating a modules block that contains all existing input modules for
>> backwards-compatibility sounds good to me too.
>>
>> One question remains: Should it be allowed to add your
>> project-specific extenstions to the object model? e.g. I like to use
>> chained input modules (i18n issues) or my own constants input modules.
>
>
> Could you explain your use case a little bit more.
Something like this:
<component-instance name="l"
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input">
<!-- first try the 'locale' request param -->
<input-module name="request-param"/>
<!-- next the session attribute -->
<input-module name="session-attr"/>
<!-- next try the request locale attribute -->
<input-module name="request-language"/>
<!-- finally use a default value -->
<input-module name="settings"/>
</component-instance>
This is useful to determine the language of my application but needs to be
configurable. Don't know if such a chain module should be part of the object
model, but why not.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>>
>> Please note that I'm not suggesting to remove the current input
>> modules. This is all about making Cocoon more coherent, not about
>> introducing back incompability. If we find a good way to replace
>> input modules I would suggest that we move them from core to an input
>> module block so that they become optional.
>>
>> WDYT?
>
>
> Having only one input module that uses a Cocoon wide object model is
> IMO a good idea. We should go through the list of all input modules
> and look where it makes sense to extend the object model.
I wrote the slightly commented list of input modules that you cutted
away from my post in the hope of geting some input about that. I use
modules that overlaps with FOM in nearly all of my sitemaps so I don't
have much opinion about the more exotic modules.
The things that I need that not is part of FOM is some type of handling
of global or sitemap specific data corresponding to e.g., DefaultsModule
or GlobalInputModule. But it is rather the handling of application
parameters than the actual input module solution that I need.
Also I have used the BaseLinkModule and some own module for URL
rewriting purposes.
Both application parameters and better sitemap related URL handling
could be part of the Context object IMO.
> Creating a modules block that contains all existing input modules for
> backwards-compatibility sounds good to me too.
>
> One question remains: Should it be allowed to add your
> project-specific extenstions to the object model? e.g. I like to use
> chained input modules (i18n issues) or my own constants input modules.
Could you explain your use case a little bit more.
Considering allowing project specific object model extensions, if we add
better URI and application parameter handling to e.g. the context
object, I'm satisfied with that. For project specific extensions I think
flowscript will be enough especially if we make it easier to use with
(flow)script actions.
But Carsten seemed to see a need for plugable object model extensions
and maybe other does. Please describe your use cases so that we can
discuss how to solve them.
/Daniel
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Please note that I'm not suggesting to remove the current input
>>> modules. This is all about making Cocoon more coherent, not about
>>> introducing back incompability. If we find a good way to replace
>>> input modules I would suggest that we move them from core to an
>>> input module block so that they become optional.
>>>
>>> WDYT?
>>
>> Having only one input module that uses a Cocoon wide object model is
>> IMO a good idea. We should go through the list of all input modules
>> and look where it makes sense to extend the object model.
>>
>> Creating a modules block that contains all existing input modules for
>> backwards-compatibility sounds good to me too.
>>
>> One question remains: Should it be allowed to add your
>> project-specific extenstions to the object model?
>
> Yes :)
>
>> e.g. I like to use chained input modules (i18n issues) or my own
>> constants input modules.
>>
> Hmm, the question is: how can a pluggable object model work - or how
> can it be extended? What about using...input modules for exactly this?
> We create a way of "mounting" input modules into the object model,
> like this:
> <object-model>
> <mount input-module="skin" path="cocoon.skin"/>
> </object-model>
>
> And then you can simple access the info by ${cocoon.skin.something}.
Thats ok for me. Any ideas about how to implement it? Right now the we
have the FlowObjectModelHelper that just take an object model and
creates a ExpressionContext (as you implemented most of it you already
know this ;) ). I guess we should make the $cocoon part of the template
object model a component so that we can configure it and don't have to
create it from scratch for each use of it. But at the same time it must
depend on the current object model. Any ideas about how to do that?
/Daniel
Re: FOM & input modules
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Hmm, the question is: how can a pluggable object model work - or how
>> can it be extended? What about using...input modules for exactly this?
>> We create a way of "mounting" input modules into the object model,
>> like this:
>> <object-model>
>> <mount input-module="skin" path="cocoon.skin"/>
>> </object-model>
>>
>> And then you can simple access the info by ${cocoon.skin.something}.
>
>
> I like it. Object model and input modules are just different names for
> similar things: accessing environmental data. Also, it's better to
> attach IMs to the cocoon object rather than as root variables, as it
> avoids name clashes with template variables.
>
> Something we have to be careful of, though, is that properties of the
> cocoon object comes both from the OM (request, response, context) and
> modules, and that it should be forbidden to have IMs having the same
> name as OM keys.
... unless cocoon.request, response, context are implemented as corresponding
input modules ... then everything under "cocoon." becomes an input module ;-)
Vadim
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Hmm, the question is: how can a pluggable object model work - or how
>>> can it be extended? What about using...input modules for exactly
>>> this? We create a way of "mounting" input modules into the object
>>> model, like this:
>>> <object-model>
>>> <mount input-module="skin" path="cocoon.skin"/>
>>> </object-model>
>>>
>>> And then you can simple access the info by ${cocoon.skin.something}.
>>
>>
>>
>>
>> I like it. Object model and input modules are just different names for
>> similar things: accessing environmental data. Also, it's better to
>> attach IMs to the cocoon object rather than as root variables, as it
>> avoids name clashes with template variables.
>>
>> Something we have to be careful of, though, is that properties of the
>> cocoon object comes both from the OM (request, response, context) and
>> modules, and that it should be forbidden to have IMs having the same
>> name as OM keys.
>>
>> I also would like to insist on the fact that FOM (flow object model)
>> is nothing more than OM (object model) that we have everywhere in
>> Cocoon, but rewrapped as JS objects. So we should better concentrate
>> on the OM itself and let its JS counterpart follow its evolutions.
>
>
>
> Thinking further (while sleeping!), it seems to me that over time we
> have abused the cocoon object in flowscript by making it an entry point
> not only to the OM, but also to some flowscript-specific utilities, e.g.
> getComponent(), processPipelineTo(), makeWebContinuation(), and of
> course cocoon.sendPageAndWait()
>
> And this causes a lot of confusion, as we use the same "cocoon" name in
> other places (jxtg) with only the OM meaning.
>
> So I think we should clearly separate the FOM (the JS wrapper of the OM)
> from the FAPI, the flowscript API which gathers flowscript-related
> utility functions by attaching them for a new "flowscript" object.
>
> We would therefore have:
> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
> - flowscript.sendPageAndWait(), flowscript.getComponent(),
> flowscript.redirect(), etc.
>
> Of course, if we choose to go that way, we must keep the current
> functions on the cocoon object for back compatibility but clearly mark
> them as deprecated.
>
> IMO, that separation would clarify things a lot, by clearly defining a
> single object model, be it in Java, flowscript, jxtg, etc.
>
> WDYT?
>
Sounds good to me - and we should define the OM (= Java API) and later
wrap it for JS.
Carsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Torsten Curdt wrote:
>>
>>>> So I think we should clearly separate the FOM (the JS wrapper of
>>>> the OM) from the FAPI, the flowscript API which gathers
>>>> flowscript-related utility functions by attaching them for a new
>>>> "flowscript" object.
>>>>
>>>> We would therefore have:
>>>> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
>>>> - flowscript.sendPageAndWait(), flowscript.getComponent(),
>>>> flowscript.redirect(), etc.
>>>
>>>
>>>
>>> sounds good to me ...one tiny thing though: I'd prefer the name
>>> "flow" ...so
>>>
>>> flow.sendPageAndWait(),
>>> flow.getComponent(),
>>> flow.redirect()
>>
>
> Why not cocoon.flow....? Do we really need another entry-point?
Because everything cocoon.xxx should be OM or IM (or only IM, as you
suggested), and be the same everywhere. Having different properties
attached to the cocoon object is what currently confuses people. At
least this is my understanding.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Torsten Curdt wrote:
>
>>> So I think we should clearly separate the FOM (the JS wrapper of the
>>> OM) from the FAPI, the flowscript API which gathers
>>> flowscript-related utility functions by attaching them for a new
>>> "flowscript" object.
>>>
>>> We would therefore have:
>>> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
>>> - flowscript.sendPageAndWait(), flowscript.getComponent(),
>>> flowscript.redirect(), etc.
>>
>>
>> sounds good to me ...one tiny thing though: I'd prefer the name "flow"
>> ...so
>>
>> flow.sendPageAndWait(),
>> flow.getComponent(),
>> flow.redirect()
Why not cocoon.flow....? Do we really need another entry-point?
>> With javaflow the whole "script" naming scheme does not really fit
>> ...even if you get a script-like behaviour with the compiling
>> classloader ...IMO
>
>
> You're falling in the same trap again ;-)
>
> Why should the flowscript API and javaflow API be the same?
As Torsten already said, they should be (if not the same but) close, and +1 to that.
Vadim
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>>> flow.sendPageAndWait(),
>>> flow.getComponent(),
>>> flow.redirect()
>>>
>>> With javaflow the whole "script" naming scheme does not really fit
>>> ...even if you get a script-like behaviour with the compiling
>>> classloader ...IMO
>>>
>>> WDYT?
>>
>>
>>
>>
>> You're falling in the same trap again ;-)
>>
>> Why should the flowscript API and javaflow API be the same? In
>> javaflow, you have access to Avalon-related data such as the service
>> manager and therefore don't need flow{script}.getComponent().
>
>
> Well, ok... the getComponent() will not be necessary
> (that was stupid ..I should have removed that line)
> ...but I am not proposing the same API - just the
> same naming scheme where possible.
>
> IMHO for the user it would be nice to see that the
> methodnames in flowscript and javaflow are very similiar.
> ...although the APIs can be different I would like to
> see the API being as close as possible.
I tend to agree with that.
--
Stefano.
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Torsten Curdt <tc...@apache.org>.
>> flow.sendPageAndWait(),
>> flow.getComponent(),
>> flow.redirect()
>>
>> With javaflow the whole "script" naming scheme does not really fit
>> ...even if you get a script-like behaviour with the compiling
>> classloader ...IMO
>>
>> WDYT?
>
>
>
> You're falling in the same trap again ;-)
>
> Why should the flowscript API and javaflow API be the same? In javaflow,
> you have access to Avalon-related data such as the service manager and
> therefore don't need flow{script}.getComponent().
Well, ok... the getComponent() will not be necessary
(that was stupid ..I should have removed that line)
...but I am not proposing the same API - just the
same naming scheme where possible.
IMHO for the user it would be nice to see that the
methodnames in flowscript and javaflow are very similiar.
...although the APIs can be different I would like to
see the API being as close as possible.
cheers
--
Torsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Curdt wrote:
>> So I think we should clearly separate the FOM (the JS wrapper of the
>> OM) from the FAPI, the flowscript API which gathers
>> flowscript-related utility functions by attaching them for a new
>> "flowscript" object.
>>
>> We would therefore have:
>> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
>> - flowscript.sendPageAndWait(), flowscript.getComponent(),
>> flowscript.redirect(), etc.
>
>
> sounds good to me ...one tiny thing though: I'd prefer the name "flow"
> ...so
>
> flow.sendPageAndWait(),
> flow.getComponent(),
> flow.redirect()
>
> With javaflow the whole "script" naming scheme does not really fit
> ...even if you get a script-like behaviour with the compiling
> classloader ...IMO
>
> WDYT?
You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In javaflow,
you have access to Avalon-related data such as the service manager and
therefore don't need flow{script}.getComponent().
So the FSAPI (flowscript API) should be defined separately from the
JFAPI (javaflow API), even if they share some concepts and/or function
names related to the fact that they both manage flow, such as
sendPageAndWait().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>> So I think we should clearly separate the FOM (the JS wrapper of the
>> OM) from the FAPI, the flowscript API which gathers flowscript-related
>> utility functions by attaching them for a new "flowscript" object.
>>
>> We would therefore have:
>> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
>> - flowscript.sendPageAndWait(), flowscript.getComponent(),
>> flowscript.redirect(), etc.
>
>
> sounds good to me ...one tiny thing though:
> I'd prefer the name "flow" ...so
>
> flow.sendPageAndWait(),
> flow.getComponent(),
> flow.redirect()
>
> With javaflow the whole "script" naming scheme does not
> really fit ...even if you get a script-like behaviour
> with the compiling classloader ...IMO
>
> WDYT?
I agree
--
Reinhard
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Torsten Curdt <tc...@apache.org>.
> So I think we should clearly separate the FOM (the JS wrapper of the OM)
> from the FAPI, the flowscript API which gathers flowscript-related
> utility functions by attaching them for a new "flowscript" object.
>
> We would therefore have:
> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
> - flowscript.sendPageAndWait(), flowscript.getComponent(),
> flowscript.redirect(), etc.
sounds good to me ...one tiny thing though:
I'd prefer the name "flow" ...so
flow.sendPageAndWait(),
flow.getComponent(),
flow.redirect()
With javaflow the whole "script" naming scheme does not
really fit ...even if you get a script-like behaviour
with the compiling classloader ...IMO
WDYT?
cheers
--
Torsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Hmm, the question is: how can a pluggable object model work - or how
>>> can it be extended? What about using...input modules for exactly
>>> this? We create a way of "mounting" input modules into the object
>>> model, like this:
>>> <object-model>
>>> <mount input-module="skin" path="cocoon.skin"/>
>>> </object-model>
>>>
>>> And then you can simple access the info by ${cocoon.skin.something}.
>>
>>
>>
>>
>> I like it. Object model and input modules are just different names for
>> similar things: accessing environmental data. Also, it's better to
>> attach IMs to the cocoon object rather than as root variables, as it
>> avoids name clashes with template variables.
>>
>> Something we have to be careful of, though, is that properties of the
>> cocoon object comes both from the OM (request, response, context) and
>> modules, and that it should be forbidden to have IMs having the same
>> name as OM keys.
>>
>> I also would like to insist on the fact that FOM (flow object model)
>> is nothing more than OM (object model) that we have everywhere in
>> Cocoon, but rewrapped as JS objects. So we should better concentrate
>> on the OM itself and let its JS counterpart follow its evolutions.
>
>
>
> Thinking further (while sleeping!), it seems to me that over time we
> have abused the cocoon object in flowscript by making it an entry point
> not only to the OM, but also to some flowscript-specific utilities, e.g.
> getComponent(), processPipelineTo(), makeWebContinuation(), and of
> course cocoon.sendPageAndWait()
>
> And this causes a lot of confusion, as we use the same "cocoon" name in
> other places (jxtg) with only the OM meaning.
>
> So I think we should clearly separate the FOM (the JS wrapper of the OM)
> from the FAPI, the flowscript API which gathers flowscript-related
> utility functions by attaching them for a new "flowscript" object.
>
> We would therefore have:
> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
> - flowscript.sendPageAndWait(), flowscript.getComponent(),
> flowscript.redirect(), etc.
>
> Of course, if we choose to go that way, we must keep the current
> functions on the cocoon object for back compatibility but clearly mark
> them as deprecated.
>
> IMO, that separation would clarify things a lot, by clearly defining a
> single object model, be it in Java, flowscript, jxtg, etc.
>
> WDYT?
Makes perfect sense.
But I think that cocoon.getComponent() would make more sense than
flowscript.getComponent() and also cocoon.request should be just 'request'.
I'm aware this is back compatibility nightmare... but consider it
brainstorming.
--
Stefano.
FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Hmm, the question is: how can a pluggable object model work - or how
>> can it be extended? What about using...input modules for exactly
>> this? We create a way of "mounting" input modules into the object
>> model, like this:
>> <object-model>
>> <mount input-module="skin" path="cocoon.skin"/>
>> </object-model>
>>
>> And then you can simple access the info by ${cocoon.skin.something}.
>
>
>
> I like it. Object model and input modules are just different names for
> similar things: accessing environmental data. Also, it's better to
> attach IMs to the cocoon object rather than as root variables, as it
> avoids name clashes with template variables.
>
> Something we have to be careful of, though, is that properties of the
> cocoon object comes both from the OM (request, response, context) and
> modules, and that it should be forbidden to have IMs having the same
> name as OM keys.
>
> I also would like to insist on the fact that FOM (flow object model)
> is nothing more than OM (object model) that we have everywhere in
> Cocoon, but rewrapped as JS objects. So we should better concentrate
> on the OM itself and let its JS counterpart follow its evolutions.
Thinking further (while sleeping!), it seems to me that over time we
have abused the cocoon object in flowscript by making it an entry point
not only to the OM, but also to some flowscript-specific utilities, e.g.
getComponent(), processPipelineTo(), makeWebContinuation(), and of
course cocoon.sendPageAndWait()
And this causes a lot of confusion, as we use the same "cocoon" name in
other places (jxtg) with only the OM meaning.
So I think we should clearly separate the FOM (the JS wrapper of the OM)
from the FAPI, the flowscript API which gathers flowscript-related
utility functions by attaching them for a new "flowscript" object.
We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(),
flowscript.redirect(), etc.
Of course, if we choose to go that way, we must keep the current
functions on the cocoon object for back compatibility but clearly mark
them as deprecated.
IMO, that separation would clarify things a lot, by clearly defining a
single object model, be it in Java, flowscript, jxtg, etc.
WDYT?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & input modules
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Hmm, the question is: how can a pluggable object model work - or how
> can it be extended? What about using...input modules for exactly this?
> We create a way of "mounting" input modules into the object model,
> like this:
> <object-model>
> <mount input-module="skin" path="cocoon.skin"/>
> </object-model>
>
> And then you can simple access the info by ${cocoon.skin.something}.
I like it. Object model and input modules are just different names for
similar things: accessing environmental data. Also, it's better to
attach IMs to the cocoon object rather than as root variables, as it
avoids name clashes with template variables.
Something we have to be careful of, though, is that properties of the
cocoon object comes both from the OM (request, response, context) and
modules, and that it should be forbidden to have IMs having the same
name as OM keys.
I also would like to insist on the fact that FOM (flow object model) is
nothing more than OM (object model) that we have everywhere in Cocoon,
but rewrapped as JS objects. So we should better concentrate on the OM
itself and let its JS counterpart follow its evolutions.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & input modules
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>>
>> Please note that I'm not suggesting to remove the current input
>> modules. This is all about making Cocoon more coherent, not about
>> introducing back incompability. If we find a good way to replace input
>> modules I would suggest that we move them from core to an input module
>> block so that they become optional.
>>
>> WDYT?
>
>
> Having only one input module that uses a Cocoon wide object model is IMO
> a good idea. We should go through the list of all input modules and look
> where it makes sense to extend the object model.
>
> Creating a modules block that contains all existing input modules for
> backwards-compatibility sounds good to me too.
>
> One question remains: Should it be allowed to add your project-specific
> extenstions to the object model?
Yes :)
> e.g. I like to use chained input
> modules (i18n issues) or my own constants input modules.
>
Hmm, the question is: how can a pluggable object model work - or how can
it be extended? What about using...input modules for exactly this? We
create a way of "mounting" input modules into the object model, like this:
<object-model>
<mount input-module="skin" path="cocoon.skin"/>
</object-model>
And then you can simple access the info by ${cocoon.skin.something}.
Carsten
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>
> Please note that I'm not suggesting to remove the current input modules.
> This is all about making Cocoon more coherent, not about introducing
> back incompability. If we find a good way to replace input modules I
> would suggest that we move them from core to an input module block so
> that they become optional.
>
> WDYT?
Having only one input module that uses a Cocoon wide object model is IMO a good
idea. We should go through the list of all input modules and look where it makes
sense to extend the object model.
Creating a modules block that contains all existing input modules for
backwards-compatibility sounds good to me too.
One question remains: Should it be allowed to add your project-specific
extenstions to the object model? e.g. I like to use chained input modules (i18n
issues) or my own constants input modules.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> So the question is, should we focus on making the FOM the main way of
>> accessing things in Cocoon or should we focus on IMs.
>>
>> Carsten's suggestion IIUC is to focus on the FOM, something that I
>> agree completely with.
>
>
> I agree with this too.
>
> If we do that we should have some kind of expression
>
>> module that could replace all other IMs and that could be used like:
>>
>> {ex:$cocoon/request/foo}
>
If we have JXPath as default expression language one could use $cocoon
as context object for JXPath and get the alternative possiblity:
{ex:request/foo}
for objects in $cocoon
>>
>> etc. By doing that people only have to learn FOM and can use that
>> everywhere. If we go this way we must see what IMs that do things
>> that not are part of FOM and maybe find a way to make them pluggable
>> in FOM.
>
>
> hmmm, than we could have something like
>
> {$defaults/skin}
> {$language/locale}
>
> And as you can see, I think we can skip the input module name, if all
> objects are part of the plugable object model.
Yes that would be nice, the question is that can be done in a way that
is back compatible with current module syntax.
>> The other alternative is to make IMs available in flow and JXTG.
>
>
> The like the idea of a plubable object model much more.
Thats good :) Ok so now we have two questions what objects that are
available in input modules but currently not is easy to access from the
object model do we want to make easier to access and how do we implement
it. I think we should focus on the first question right now.
Taking a quick look at the modules I would sugest that we have some sets
of modules with various properties:
Overlaps with FOM
-----------------
These modules does thing that is easy to do with FOM and an expression
language AFAIU:
FlowAttributeModule
FlowContinuationModule
HeaderAttributeModule
RawRequestParametersModule
RealPathModule
RequestAttributeModule
RequestModule
RequestURIModule
SessionAttributeModule
SessionModule
Might be interesting in FOM
---------------------------
These give access to objects that not are part of FOM AFAIK and could be
usable both in the sitemap, JXTG and flow:
DefaultsModule
GlobalInputModule
NamingInputModule
PropertiesFileModule
XMLFileModule
We have some modules that are functions on URIs rather than accessing
some object:
DigestMetaModule
URLDecodeModule
URLEncodeModule
And some that apply some functionality on an object that is part of FOM:
BaseLinkModule
--- o0o ---
Besides the listed modules we have a set of meta modules that AFAIU
gives the possiblity to create some kind of "expressions" based on
modules, is this needed when we have flow and expression languages on a FOM?
There are also some modules that I don't know anything about and didn't
list.
Also all more advanced use of input modules could probably better be
replaced by a short flowscript call. And we should at least take into
account the possiblity that we don't need any pluggable object models at
all and that flow is enough.
--- o0o ---
Please note that I'm not suggesting to remove the current input modules.
This is all about making Cocoon more coherent, not about introducing
back incompability. If we find a good way to replace input modules I
would suggest that we move them from core to an input module block so
that they become optional.
WDYT?
/Daniel
FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> So the question is, should we focus on making the FOM the main way of
> accessing things in Cocoon or should we focus on IMs.
>
> Carsten's suggestion IIUC is to focus on the FOM, something that I agree
> completely with.
I agree with this too.
If we do that we should have some kind of expression
> module that could replace all other IMs and that could be used like:
>
> {ex:$cocoon/request/foo}
>
> etc. By doing that people only have to learn FOM and can use that
> everywhere. If we go this way we must see what IMs that do things that
> not are part of FOM and maybe find a way to make them pluggable in FOM.
hmmm, than we could have something like
{$defaults/skin}
{$language/locale}
And as you can see, I think we can skip the input module name, if all objects
are part of the plugable object model.
> The other alternative is to make IMs available in flow and JXTG.
The like the idea of a plubable object model much more.
> In any
> case we should be able to use everything that is usable from IMs in flow
> and JXTG as well, so we should do something about it.
--
Reinhard
Re: WishFull thinking JX and SessionContext Authentication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
oceatoon wrote:
>>Then I think that it shouldn't be part of the JXTG code but rather part
>>of the TemplateObjectModelHelper or some supporting classes, that in
>>turn are used by JXTG. This way it could be used outside JXTG.
>>>>>>Wouldn't it be better if JXTG supported input modules with syntax
>>>>>>like:
>>>>>>
>>>>>>{im:moduleName:valueName}
>
> HOw about ${inputmodulename(params)}, so it stays jexl like syntax?
The syntax above is based on that the new pluggable expressions are used
like
jxpath:$a+2, jexl:a+2 or just $a+2
if we had jxpath as default expression language. Then the idea was to
make a pluggable expreesion embeding of input modules also so that input
modules are considered as some kind of expressions. That would give the
syntax above.
Now I'm not certain about how that should work as expressions take an
ExpressionContext as input and input modules takes an object model.
<snip/>
> Talking about making cocoon easy to understand, I have a hard time seeing
> the pros and cons of the pluggable ObjectModels, certainly because I don't
> see the whole picture around it(maybe some naive explaining would
> help,THX). OTOH, I can see great use of the last one (IM).
The idea with input modules was to give access to various context
objects, request, session etc in e.g. the sitemap. This task overlaps
quite a lot with the flow object model (FOM) in flow and especially with
the "view" FOM that is used in JXTG.
For making Cocoon easier to understand and maintain it is better to have
one way of doing a thing than two essentially equivalent that are used
in different contexts.
So the question is, should we focus on making the FOM the main way of
accessing things in Cocoon or should we focus on IMs.
Carsten's suggestion IIUC is to focus on the FOM, something that I agree
completely with. If we do that we should have some kind of expression
module that could replace all other IMs and that could be used like:
{ex:$cocoon/request/foo}
etc. By doing that people only have to learn FOM and can use that
everywhere. If we go this way we must see what IMs that do things that
not are part of FOM and maybe find a way to make them pluggable in FOM.
The other alternative is to make IMs available in flow and JXTG. In any
case we should be able to use everything that is usable from IMs in flow
and JXTG as well, so we should do something about it.
/Daniel
Re: WishFull thinking JX and SessionContext Authentication
Posted by oceatoon <t....@systheo.com>.
> Then I think that it shouldn't be part of the JXTG code but rather part
> of the TemplateObjectModelHelper or some supporting classes, that in
> turn are used by JXTG. This way it could be used outside JXTG.
>
>>>>> Wouldn't it be better if JXTG supported input modules with syntax
>>>>> like:
>>>>>
>>>>> {im:moduleName:valueName}
HOw about ${inputmodulename(params)}, so it stays jexl like syntax?
> Don't know if I like that, modules and expressions are a little bit
> overlapping as many modules are using JXPath. The question is who should
> call who. And I'm not certain that:
>
> {im:flow-attr:jexl:foo.bar}
>
> would help making Cocoon easy to use and understand ;)
That's another story ;)
>
>>>> Don't know :) Sure, this is one solution - my idea is a little bit
>>>> different:
>>>> we could provide a pluggable object model and then use this object
>>>> model in jxtg,
>>>> but also in input modules - so in fact you would only need one input
>>>> module and can use the same syntax there as in jxtg. I'm not sure if
>>>> this makes sense, but if it does, we wouldn't need input modules
>>>> anymore.
>
> >>> Carsten
>
> Makes sense to me, I would also prefer going this direction. Having one
> prefered way to access things and using it everywhere will make Cocoon
> easier to learn. And we can focus our work on one implementation.
>
> We need to identify which modules that give access to something that not
> allready is part of FOM and discuss which of them that we want to make
> accessable from FOM.
>
> Then we could put all the module in a block and thus get rid of the most
> exotic (mis)uses of the module concept from core.
>
> Maybe we could make the FOM pluggable so that we have a configuration
> where one decides what object that shoud be part of FOM.
>
> Then on the other hand we shouldn't overdo it. More specialized pluging
> can always be done in flow:
>
>>> don't we have a pluggable object model ? :))
>>>
>>> function doIt() {
>>> var objectModel = {};
>>>
>>> objectModel.pluggedIn1 = entityFromDatabase();
>>> objectModel.pluggedIn2 = request.getParameter( "skin" );
>>>
>>> cocoon.sendPage( "view/myview.jx", objectModel );
>>> }
>
> I would go further:
>
> function doIt() {
> var objectModel = {};
>
> objectModel.pluggedIn1 = entityFromDatabase();
> objectModel.pluggedIn2 = request.getParameter( "skin" );
>
> return objectModel;
> }
>
> <match pattern="foo">
> <call function="doIt"/>
> <generate type="jx" src="foo"/>
> ...
> </match>
>
> Or whatever syntax we choose for (flow)script actions. The idea is that
> the flow context is the return value from the function.
>
> I'll start to discuss design and work on this after the JXTG refactoring
> if no one else does it before me and if the community agrees.
>
>>> Other data that is not directly available from flow (like
>>> authentication context can be accessed with input modules that are
>>> already available).
>>>
>> something like this in flow would be useful:
>>
>> function doIt() {
>> var objectModel = {
>> skin: cocoon.inputModule.defaults.getValue( "skin" )};
>>
>> cocoon.sendPage( "view/myview.jx", objectModel );
>>
Talking about making cocoon easy to understand, I have a hard time seeing
the pros and cons of the pluggable ObjectModels, certainly because I don't
see the whole picture around it(maybe some naive explaining would
help,THX). OTOH, I can see great use of the last one (IM).
> I would prefer to do as outlined above, identify what or maybe if we are
> missing something from some input modules and make that functionality
> available in $cocoon or through flow.
if input modules are functional in jx and Flow what else do we need appart
for writting all the IM's we need.
regards
Tibor
Re: WishFull thinking JX and SessionContext Authentication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote:
>>>> Carsten Ziegeler wrote:
>>>>> oceatoon wrote:
>>>>>
>>>>>> This is wishfull thinking and probably no news to those
>>>>>> refactoring JX. But
>>>>>> access to the session context object like the session-context
>>>>>> input module
>>>>>> would be great (like for example with the authentication context).
>>>>>> I have
>>>>>> found other post asking about and for this sort of functionality.
>>>>>> it would
>>>>>> smoothen quite a bit the access to such inportant elements as the
>>>>>> ones in
>>>>>> session-context (like authentication data).
>>>>>>
>>>>> Yes, this should be possible, I agree. I hope that the refactored
>>>>> version will be pluggable to plug-in some kind of adapter to access
>>>>> "own data" like the authentication context etc.
You don't need to just hope, you can either implement it or describe how
it should work so that someone else can do it ;)
Then I think that it shouldn't be part of the JXTG code but rather part
of the TemplateObjectModelHelper or some supporting classes, that in
turn are used by JXTG. This way it could be used outside JXTG.
>>>> Wouldn't it be better if JXTG supported input modules with syntax like:
>>>>
>>>> {im:moduleName:valueName}
Don't know if I like that, modules and expressions are a little bit
overlapping as many modules are using JXPath. The question is who should
call who. And I'm not certain that:
{im:flow-attr:jexl:foo.bar}
would help making Cocoon easy to use and understand ;)
>>> Don't know :) Sure, this is one solution - my idea is a little bit
>>> different:
>>> we could provide a pluggable object model and then use this object
>>> model in jxtg,
>>> but also in input modules - so in fact you would only need one input
>>> module and can use the same syntax there as in jxtg. I'm not sure if
>>> this makes sense, but if it does, we wouldn't need input modules
>>> anymore.
>>> Carsten
Makes sense to me, I would also prefer going this direction. Having one
prefered way to access things and using it everywhere will make Cocoon
easier to learn. And we can focus our work on one implementation.
We need to identify which modules that give access to something that not
allready is part of FOM and discuss which of them that we want to make
accessable from FOM.
Then we could put all the module in a block and thus get rid of the most
exotic (mis)uses of the module concept from core.
Maybe we could make the FOM pluggable so that we have a configuration
where one decides what object that shoud be part of FOM.
Then on the other hand we shouldn't overdo it. More specialized pluging
can always be done in flow:
>> don't we have a pluggable object model ? :))
>>
>> function doIt() {
>> var objectModel = {};
>>
>> objectModel.pluggedIn1 = entityFromDatabase();
>> objectModel.pluggedIn2 = request.getParameter( "skin" );
>>
>> cocoon.sendPage( "view/myview.jx", objectModel );
>> }
I would go further:
function doIt() {
var objectModel = {};
objectModel.pluggedIn1 = entityFromDatabase();
objectModel.pluggedIn2 = request.getParameter( "skin" );
return objectModel;
}
<match pattern="foo">
<call function="doIt"/>
<generate type="jx" src="foo"/>
...
</match>
Or whatever syntax we choose for (flow)script actions. The idea is that
the flow context is the return value from the function.
I'll start to discuss design and work on this after the JXTG refactoring
if no one else does it before me and if the community agrees.
>> Other data that is not directly available from flow (like
>> authentication context can be accessed with input modules that are
>> already available).
>>
> something like this in flow would be useful:
>
> function doIt() {
> var objectModel = {
> skin: cocoon.inputModule.defaults.getValue( "skin" )};
>
> cocoon.sendPage( "view/myview.jx", objectModel );
>
> that would require FOM to be extended. WDYT?
IIRC modules was part of flow once but removed after a vote as people
thought that most of the things you can do with modules can be done in a
less clumsy way with the FOM and ordinary JS constructs and that where
was no reason do duplicate functionality.
I would prefer to do as outlined above, identify what or maybe if we are
missing something from some input modules and make that functionality
available in $cocoon or through flow.
/Daniel
Re: WishFull thinking JX and SessionContext Authentication
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>
>> Leszek Gawron wrote:
>>
>>> Carsten Ziegeler wrote:
>>>
>>>> oceatoon wrote:
>>>>
>>>>> This is wishfull thinking and probably no news to those refactoring
>>>>> JX. But
>>>>> access to the session context object like the session-context input
>>>>> module
>>>>> would be great (like for example with the authentication context).
>>>>> I have
>>>>> found other post asking about and for this sort of functionality.
>>>>> it would
>>>>> smoothen quite a bit the access to such inportant elements as the
>>>>> ones in
>>>>> session-context (like authentication data).
>>>>>
>>>> Yes, this should be possible, I agree. I hope that the refactored
>>>> version will be pluggable to plug-in some kind of adapter to access
>>>> "own data" like the authentication context etc.
>>>
>>>
>>>
>>>
>>> Wouldn't it be better if JXTG supported input modules with syntax like:
>>>
>>> {im:moduleName:valueName}
>>>
>>> ?
>>
>>
>> Don't know :) Sure, this is one solution - my idea is a little bit
>> different:
>> we could provide a pluggable object model and then use this object
>> model in jxtg,
>> but also in input modules - so in fact you would only need one input
>> module and can use the same syntax there as in jxtg. I'm not sure if
>> this makes sense, but if it does, we wouldn't need input modules anymore.
>>
>> Carsten
>>
> don't we have a pluggable object model ? :))
>
> function doIt() {
> var objectModel = {};
>
> objectModel.pluggedIn1 = entityFromDatabase();
> objectModel.pluggedIn2 = request.getParameter( "skin" );
>
> cocoon.sendPage( "view/myview.jx", objectModel );
> }
>
> Other data that is not directly available from flow (like authentication
> context can be accessed with input modules that are already available).
>
something like this in flow would be useful:
function doIt() {
var objectModel = {
skin: cocoon.inputModule.defaults.getValue( "skin" )};
cocoon.sendPage( "view/myview.jx", objectModel );
that would require FOM to be extended. WDYT?
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: WishFull thinking JX and SessionContext Authentication
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> oceatoon wrote:
>>>
>>>> This is wishfull thinking and probably no news to those refactoring
>>>> JX. But
>>>> access to the session context object like the session-context input
>>>> module
>>>> would be great (like for example with the authentication context). I
>>>> have
>>>> found other post asking about and for this sort of functionality. it
>>>> would
>>>> smoothen quite a bit the access to such inportant elements as the
>>>> ones in
>>>> session-context (like authentication data).
>>>>
>>> Yes, this should be possible, I agree. I hope that the refactored
>>> version will be pluggable to plug-in some kind of adapter to access
>>> "own data" like the authentication context etc.
>>
>>
>>
>> Wouldn't it be better if JXTG supported input modules with syntax like:
>>
>> {im:moduleName:valueName}
>>
>> ?
>
> Don't know :) Sure, this is one solution - my idea is a little bit
> different:
> we could provide a pluggable object model and then use this object model
> in jxtg,
> but also in input modules - so in fact you would only need one input
> module and can use the same syntax there as in jxtg. I'm not sure if
> this makes sense, but if it does, we wouldn't need input modules anymore.
>
> Carsten
>
don't we have a pluggable object model ? :))
function doIt() {
var objectModel = {};
objectModel.pluggedIn1 = entityFromDatabase();
objectModel.pluggedIn2 = request.getParameter( "skin" );
cocoon.sendPage( "view/myview.jx", objectModel );
}
Other data that is not directly available from flow (like authentication
context can be accessed with input modules that are already available).
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: WishFull thinking JX and SessionContext Authentication
Posted by Carsten Ziegeler <cz...@apache.org>.
oceatoon wrote:
> do you mean input modules would be pluggable objects and we could create our
> own object to be used ? but in that case why not simply create another IM?
> And IM are quite usefull all over cocoon, don't you think?
>
IM are usefull, no doubt and yes it could be done with input modules. I
just thought that instead of writing {im:some_path} (explicitly using
the IM), just being able to use {some_path} would be nicer.
It's just a thought...
Carsten
Re: WishFull thinking JX and SessionContext Authentication
Posted by oceatoon <t....@systheo.com>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>
>>> oceatoon wrote:
>>>
>>>> This is wishfull thinking and probably no news to those refactoring
>>>> JX. But
>>>> access to the session context object like the session-context input
>>>> module
>>>> would be great (like for example with the authentication context). I
>>>> have
>>>> found other post asking about and for this sort of functionality. it
>>>> would
>>>> smoothen quite a bit the access to such inportant elements as the
>>>> ones in
>>>> session-context (like authentication data).
>>>>
>>> Yes, this should be possible, I agree. I hope that the refactored
>>> version will be pluggable to plug-in some kind of adapter to access
>>> "own data" like the authentication context etc.
>>
>>
>> Wouldn't it be better if JXTG supported input modules with syntax like:
>>
>> {im:moduleName:valueName}
>>
>> ?
Yes that would be even better
> Don't know :) Sure, this is one solution - my idea is a little bit
> different:
> we could provide a pluggable object model and then use this object model
> in jxtg,
> but also in input modules - so in fact you would only need one input
> module and can use the same syntax there as in jxtg. I'm not sure if
> this makes sense, but if it does, we wouldn't need input modules anymore.
do you mean input modules would be pluggable objects and we could create our
own object to be used ? but in that case why not simply create another IM?
And IM are quite usefull all over cocoon, don't you think?
Tibor
Re: WishFull thinking JX and SessionContext Authentication
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>
>> oceatoon wrote:
>>
>>> This is wishfull thinking and probably no news to those refactoring
>>> JX. But
>>> access to the session context object like the session-context input
>>> module
>>> would be great (like for example with the authentication context). I
>>> have
>>> found other post asking about and for this sort of functionality. it
>>> would
>>> smoothen quite a bit the access to such inportant elements as the
>>> ones in
>>> session-context (like authentication data).
>>>
>> Yes, this should be possible, I agree. I hope that the refactored
>> version will be pluggable to plug-in some kind of adapter to access
>> "own data" like the authentication context etc.
>
>
> Wouldn't it be better if JXTG supported input modules with syntax like:
>
> {im:moduleName:valueName}
>
> ?
Don't know :) Sure, this is one solution - my idea is a little bit
different:
we could provide a pluggable object model and then use this object model
in jxtg,
but also in input modules - so in fact you would only need one input
module and can use the same syntax there as in jxtg. I'm not sure if
this makes sense, but if it does, we wouldn't need input modules anymore.
Carsten
Re: WishFull thinking JX and SessionContext Authentication
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> oceatoon wrote:
>
>> This is wishfull thinking and probably no news to those refactoring
>> JX. But
>> access to the session context object like the session-context input
>> module
>> would be great (like for example with the authentication context). I have
>> found other post asking about and for this sort of functionality. it
>> would
>> smoothen quite a bit the access to such inportant elements as the ones in
>> session-context (like authentication data).
>>
> Yes, this should be possible, I agree. I hope that the refactored
> version will be pluggable to plug-in some kind of adapter to access "own
> data" like the authentication context etc.
Wouldn't it be better if JXTG supported input modules with syntax like:
{im:moduleName:valueName}
?
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: WishFull thinking JX and SessionContext Authentication
Posted by Carsten Ziegeler <cz...@apache.org>.
oceatoon wrote:
> This is wishfull thinking and probably no news to those refactoring JX. But
> access to the session context object like the session-context input module
> would be great (like for example with the authentication context). I have
> found other post asking about and for this sort of functionality. it would
> smoothen quite a bit the access to such inportant elements as the ones in
> session-context (like authentication data).
>
Yes, this should be possible, I agree. I hope that the refactored
version will be pluggable to plug-in some kind of adapter to access "own
data" like the authentication context etc.
Carsten