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.
