RE: FOM, views, and input modules
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
I modified the FOM implementation in the scratchpad to make the FOM
available to the view layer, thinking that the view author
also should
see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw
Request, Response, etc. Do others agree with this?
The same is valid for the view layer as explained from you below!
You can still pass parameters to generators or transformers of pipelines
called by the flow layer.
Additionally you can call pipelines that contain actions. Do we want
this?
I'm worried that people start to work around the restrictions of the FOM
...
I also modified the GarbageGenerator to use the FOM.
So because of the FOM you can't do this in a flow script anymore:
cocoon.request.sitemapURI
likewise in a Garbage view template you can no longer do this:
page whatever={$request/sitemapURI}
in both cases because the FOM doesn't expose the sitemapURI
property
of the Request.
However the input modules give full access to the original
Java Request
object, so in the sitemap you can still do this:
map:call function=whatever
map:parameter name=whatever value={request:sitemapURI}/
and pass it as a parameter to your flowscript, bypassing the FOM (!)
This seems inconsistent to me. What do others think?
Yes, you are right! Maybe we should disable input module substituion
within
call elements of the sitemap. (I don't know if this is possible at all.)
What do you think?
Reinhard
Re: FOM, views, and input modules
on 6/25/03 4:35 AM Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
I modified the FOM implementation in the scratchpad to make the FOM
available to the view layer, thinking that the view author
also should
see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw
Request, Response, etc. Do others agree with this?
I see no disadvantage.
The same is valid for the view layer as explained from you below!
You can still pass parameters to generators or transformers of pipelines
called by the flow layer.
Additionally you can call pipelines that contain actions. Do we want
this?
if someone wants to use actions in their pipelines, it's their choice,
we should not restrict anything in the sitemap from the flow.
I'm worried that people start to work around the restrictions of the FOM
We should not think we know it all. The FOM can be designed to limit
the ability to abuse, but there is no way we can prevent abuse even if
we want to and, besides, what we consider abuse today, might become good
practice tomorrow (or viceversa).
So, don't be too concerned.
I also modified the GarbageGenerator to use the FOM.
That's awesome.
So because of the FOM you can't do this in a flow script anymore:
cocoon.request.sitemapURI
likewise in a Garbage view template you can no longer do this:
page whatever={$request/sitemapURI}
in both cases because the FOM doesn't expose the sitemapURI
property
of the Request.
Yes.
However the input modules give full access to the original
Java Request
object, so in the sitemap you can still do this:
map:call function=whatever
map:parameter name=whatever value={request:sitemapURI}/
and pass it as a parameter to your flowscript, bypassing the FOM (!)
This seems inconsistent to me. What do others think?
Having a completely consistent architecture in an open source project is
impossible, because it's developped in an incremental way and it's hard
to deprecate things because people get used to them.
Inconsistency is not, again, necessarely a bad thing from an design
evolution perspective.
The reason not to expose sitemapURI is to promote the use of link
translation, that is IOC applied to URI referencing.
But I expect this to take a while to catch up, so i think it's good
there is a way to bypass what is now considered as a FOM limitation
without requiring deprecation of methods in the future.
Yes, you are right! Maybe we should disable input module substituion
within
call elements of the sitemap. (I don't know if this is possible at all.)
What do you think?
-1, it's too harsh and people would not understand why we are doing this.
i simply expect people to stop asking for URI fragments to the request
to assemble the URI calls by themselves and let the link translation
transformers do it for them.
But again, we have to show what we consider a best practice so that
people can follow.
--
Stefano.
Re: FOM, views, and input modules
On Monday, June 23, 2003, at 04:57 AM, Christopher Oliver wrote:
I modified the FOM implementation in the scratchpad to make the FOM
available to the view layer, thinking that the view author also should
see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw
Request, Response, etc. Do others agree with this?
I also modified the GarbageGenerator to use the FOM.
So because of the FOM you can't do this in a flow script anymore:
cocoon.request.sitemapURI
likewise in a Garbage view template you can no longer do this:
page whatever={$request/sitemapURI}
in both cases because the FOM doesn't expose the sitemapURI property
of the Request.
However the input modules give full access to the original Java
Request object, so in the sitemap you can still do this:
map:call function=whatever
map:parameter name=whatever value={request:sitemapURI}/
and pass it as a parameter to your flowscript, bypassing the FOM (!)
This seems inconsistent to me. What do others think?
I like to have access to the URI of the request from within the
flowscript.
Specially because I put my Continuation in a request param and match it
with the RequestParam Matcher (I hate seeing that in the URL).
So passing the URI from the sitemap is not so easy in my case
regards Jeremy
