You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2004/11/02 19:21:35 UTC
[RT] Attribute Rendering and CForms Convertors (was: Templating Engine
- Next steps?)
Bart Molenkamp wrote:
> I've also been thinking about a simple method for displaying object
>
>instances of different classes. E.g. I get an object from the flow
>layer, I need to decide how to format it. Instances of class "A" are
>formatted differently than instances from class "B". Now, this could be
>done using <jx:choose>, but that doesn't make the code more readable:
>
><!-- is object instanceof MyClass -->
><jx:when test="object.getClass().getName() == 'com.MyClass'">
>
>Even worse when you want to check if it is instanceof an interface:
>
><!-- is object instanceof MyInterface -->
><jx:when
>test="${java.lang.Class.forName('com.MyInterface').isAssignableFrom(
>object.getClass())}">
>
>
I don't know your use cases, so maybe not the following is applicable at
all, anyway:
In the (often cited on this list) article: Enforcing Strict Model View
Separation in Template Engines, by Terence Parr
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, a number of
rules for strict separation between model and view are given. One of
them is that the view shouldn't make any assumptions about data types of
the model data. The view should only get displayable strings. If one
start to depend on data types as in your code above, the template files
must be supported by programmers rather than web designers. And the
separation of concern between view and model start to get entangeled.
Ok, knowing what Terence Parr _don't_ want us to do is not very helpfull ;)
As a solution to the problem he sugests MVCR
(Model-View-Controller-Renderer), where the renderer is responsible for
converting (Java) data types to displayable strings. The renderer can be
responsible for localization of numbers etc as well. The renderer is an
extra step between model and view.
The simplest possible renderer is to just implement toString() in the
classes one is going to access in the view. But a better SoC is to have
a separate rendering component. In this case the object from the model
is first accessed by an expression in a suitable expression language and
then the object is rendered to a displayable string by the rendering
component and at last the displayable string is emited by the template
engine.
So, how would the rendering component work? I think that we basically
could reuse and extend the Convertor idea from CForms. The renderer
check the type of the input object (and possibly the locale) and applies
the apropriate convertor. The coupling between object type and convertor
is decribed in a configuration file, much as in the form definition in
CForms. It should also be easy to use custom converters, for own data types.
Typically one can reuse the same rendering configuration file for all
templates.
---o0o---
I think the renderer component idea could give a better SoC in CForms as
well. I have had a feeling that data type convertion is not a natural
part of the model (form definition) for a while. A problem is that
conversion configuration must be repeated each time the data type is used.
Ok, the idea is as follows: we have a converter component, that is like
the renderer component above, but bidirectional. I.e. both rendering:
data type -> displayable string and input conversion: input string ->
data type. The converter is configured in the same way as described for
the renderer above.
The convertor is used as a step between the form instance and the view
for rendering the data types. And between the request object and the
form instance during the population of the form instance.
Typically only one convertor configuration is needed for all ones forms.
And we could distribute a localized default convertor configuration with
Cocoon.
---o0o---
So, the basic idea is to factor out the type conversion functionallity
from CForms and make it available for all rendering and input handling
needs in Cocoon.
WDYT?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
> On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:
>>Ok, the idea is as follows: we have a converter component, that is like
>>the renderer component above, but bidirectional. I.e. both rendering:
>>data type -> displayable string and input conversion: input string ->
>>data type. The converter is configured in the same way as described for
>>the renderer above.
>
> I've been working along the same line [1] (it's about a widget framework
> but contains elements that are relevant to your idea as well). The idea
> is that data is wrapped by a model that works directly on my data but
> that can perform any conversions, validations etc through its
> getValue/setValue functions:
>
> public interface Model {
> public String getValue(String path);
> public void setValue(String path, String value);
> }
>
IMO, such an interface is a good starting point, although it needs
exceptions for cases when conversion fails. In some cases like when you
can build lists or trees in the user interface, a more traversal based
interface is needed.
Also, like everyone else that has commented your proposal, I think that
it often is a bad idea to write directly to your model. Even if you are
able to solve the security problems, the model will still need to be
able to store partially invalid input data and missing data. IMO it is
better SoC to have a form model in front of the real model. This
decreases the complexity of the model as it always can get data in a
more transactinal way in complete chunks.
I prefer the request processor idea to the current form population where
each widget reads it data from the request object. The current scheme
makes CForms unecesarily bound to the request parameter model of input
data. With a request processor that is reponsible to write input data
into the form model, it would be easy to plug in a different request
processor if one gets xml input from a browser that implements XForms, e.g.
> For example if my data is a bean containing a Date then a
> ConvertingBeanModel wrapping my bean would have a getValue function
> performing the Date->String conversion (according to whatever locale is
> chosen). And vice versa with setValue. The benefit with having an
> abstract view of the model would be that you can implement any type of
> conversion in the setValue/getValue functions. You could have a generic
> set of conversions for the basic types as well as special conversions
> unique to your application. Eg. if your underlying data is a resultset
> then you can convert values to SQL types rather than java types.
If we translate this to the CForms case, generic sets of convertors,
would not only be useful for rendering and handling input to the widget
hierarchy, they would be useful in the binding step also.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Tim Larson <ti...@keow.org>.
On Wed, Nov 03, 2004 at 09:46:27PM +0100, Daniel Fagerstrom wrote:
> I prefer the request processor idea to the current form population where
> each widget reads it data from the request object. The current scheme
> makes CForms unecesarily bound to the request parameter model of input
> data. With a request processor that is reponsible to write input data
> into the form model, it would be easy to plug in a different request
> processor if one gets xml input from a browser that implements XForms, e.g.
This change would also be good for xmlhttprequest support.
--Tim Larson
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Reinhard Poetz <re...@apache.org>.
Jonas Ekstedt wrote:
> On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
>
>>Jonas Ekstedt wrote:
>>
>>
>>>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
>>>
>>>
>>
>><snip/>
>>
>>>>>Another way of doing the same, which I think was the agreed upon way to
>>>>>do it is to populate all widgets that has a request parameter present.
>>>>>This works out the same way with one little caveat. Some day someone is
>>>>>going to do
>>>>>
>>>>><jx:if test="${user.role == 'admin'}">
>>>>><ft:widget id="bigDangerousButton"/>
>>>>></jx:if>
>>>>>
>>>>>and will be in for a mighty surprise.
>>>>>
>>>>>
>>>>
>>>>I don't follow you here can you give some more details for that scenario.
>>>>
>>>>
>>>
>>>What I meant was that in the scenario above a malicious user can add a
>>>request parameter "bigDangerousButton" to the POST and it will be
>>>processed by the population mechanism (firing off button events) even if
>>>the user has role "user" in the example above. I think this would
>>>actually be quite a common usecase having one form template rendered
>>>differently depending on what type of user access it. The problem is
>>>that a population mechanism without knowledge of what has been rendered
>>>cannot make decisions about which widgets are eligible for population.
>>>
>>>
>>
>>On that particular point, it seems to me *especially dangerous* to let
>>the template decide what what widgets are to be displayed depending on
>>user roles.
>>
>>ACL is an application-level concern, and *must* be handled by the
>>controller and/or the application logic. That's what widget states
>>allow: by setting the "bigDangerousButton" state to invisible, you don't
>>even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will
>>simply render nothing if the widget's state is invisible.
>
>
> The problem with this approach is that normally (I would think at least)
> widget states will be changed in a manner orthogonal to the widget
> hierarchy. The widgets being hidden will be all over the form rather
> than under one single fd:struct that can be switched on/off.
>
> Take the current project I'm working on. I have a Taxon (4 subclasses)
> which contains a list of Specifiers (3 subclasses) which contains a list
> of Tokens (4 subclasses). Each of the subclasses are rendered
> differently depending on class and whether they are edited or viewed.
> The user can also choose whether to view/edit the whole hierarchy at
> once or only parts of it.
>
> To do this I use one jxmacro for each subclass. The macro renders form
> fields if ${edit == 'true'} or text otherwise. It would be a nightmare
> trying to do this with CForm as I would have to walk around the entire
> widget tree setting widget states when switching between editing and
> viewing.
I have to admit that I don't understand your usecase completly but rendering
form fields depending on an editable value and rendering them depending on the
type should be done using stylesheets (XSLT) and not in an XML template.
Templates and the FormsTransformer only generate data in a particular structure
and don't contain layout information but only hints for the stylesheets (e.g.
the information if a widget is editable or not). They don't know how to render
the form e.g. that a non-editable form field should be displayed as plain text.
--
Reinhard
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
>
>
<snip/>
>>Looks to me this is the perfect use case for union and class widgets in
>>CForms. I had similar use-cases for an IDE-like webapp, and these
>>widgets made wonders.
>>
>>Also, have you looked at the "form gui" and "swan" samples where they
>>are heavily showcased?
>>
>>
>>
>
>I humbly request for permission to crawl back under a rock ;)
>
Don't forget to take a laptop under your rock to study CForms samples ;-P
>Looking through the union and class samples, that seems to be exactly what I need.
>
>
You know, CForms has been developped for more than 18 months by a lot of
people. So what we have today is the result of many shared brain cycles.
Although it certainly can be (and will be) improved in some areas, it is
solid, it works and is used in large scale applications.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Wed, 2004-11-17 at 06:34 +0100, Jonas Ekstedt wrote:
>
>
>>On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
>>
>>
>>>Also, have you looked at the "form gui" and "swan" samples where they
>>>are heavily showcased?
>>>
>>>
>>>
>>I humbly request for permission to crawl back under a rock ;) . Looking
>>through the union and class samples, that seems to be exactly what I
>>need.
>>
>>
>
>Just to avoid any misunderstandings. What I meant to say was that the
>samples fits my usecase perfectly.
>
>
That's what I understood :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-17 at 06:34 +0100, Jonas Ekstedt wrote:
> On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
> > Also, have you looked at the "form gui" and "swan" samples where they
> > are heavily showcased?
> >
>
> I humbly request for permission to crawl back under a rock ;) . Looking
> through the union and class samples, that seems to be exactly what I
> need.
Just to avoid any misunderstandings. What I meant to say was that the
samples fits my usecase perfectly.
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
>
> >On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
> >
> >
> >>Jonas Ekstedt wrote:
> >>
> >>
> >>
> >>>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> >>>
> >>>
> >>>
> >>>
> >><snip/>
> >>
> >>
> >>
> >>>>>Another way of doing the same, which I think was the agreed upon way to
> >>>>>do it is to populate all widgets that has a request parameter present.
> >>>>>This works out the same way with one little caveat. Some day someone is
> >>>>>going to do
> >>>>>
> >>>>><jx:if test="${user.role == 'admin'}">
> >>>>><ft:widget id="bigDangerousButton"/>
> >>>>></jx:if>
> >>>>>
> >>>>>and will be in for a mighty surprise.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>I don't follow you here can you give some more details for that scenario.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>What I meant was that in the scenario above a malicious user can add a
> >>>request parameter "bigDangerousButton" to the POST and it will be
> >>>processed by the population mechanism (firing off button events) even if
> >>>the user has role "user" in the example above. I think this would
> >>>actually be quite a common usecase having one form template rendered
> >>>differently depending on what type of user access it. The problem is
> >>>that a population mechanism without knowledge of what has been rendered
> >>>cannot make decisions about which widgets are eligible for population.
> >>>
> >>>
> >>>
> >>>
> >>On that particular point, it seems to me *especially dangerous* to let
> >>the template decide what what widgets are to be displayed depending on
> >>user roles.
> >>
> >>ACL is an application-level concern, and *must* be handled by the
> >>controller and/or the application logic. That's what widget states
> >>allow: by setting the "bigDangerousButton" state to invisible, you don't
> >>even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will
> >>simply render nothing if the widget's state is invisible.
> >>
> >>
> >
> >The problem with this approach is that normally (I would think at least)
> >widget states will be changed in a manner orthogonal to the widget
> >hierarchy. The widgets being hidden will be all over the form rather
> >than under one single fd:struct that can be switched on/off.
> >
> >Take the current project I'm working on. I have a Taxon (4 subclasses)
> >which contains a list of Specifiers (3 subclasses) which contains a list
> >of Tokens (4 subclasses). Each of the subclasses are rendered
> >differently depending on class and whether they are edited or viewed.
> >The user can also choose whether to view/edit the whole hierarchy at
> >once or only parts of it.
> >
> >To do this I use one jxmacro for each subclass. The macro renders form
> >fields if ${edit == 'true'} or text otherwise. It would be a nightmare
> >trying to do this with CForm as I would have to walk around the entire
> >widget tree setting widget states when switching between editing and
> >viewing.
> >
> >
>
> Looks to me this is the perfect use case for union and class widgets in
> CForms. I had similar use-cases for an IDE-like webapp, and these
> widgets made wonders.
>
> Also, have you looked at the "form gui" and "swan" samples where they
> are heavily showcased?
>
I humbly request for permission to crawl back under a rock ;) . Looking
through the union and class samples, that seems to be exactly what I
need.
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
>
>
>>Jonas Ekstedt wrote:
>>
>>
>>
>>>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
>>>
>>>
>>>
>>>
>><snip/>
>>
>>
>>
>>>>>Another way of doing the same, which I think was the agreed upon way to
>>>>>do it is to populate all widgets that has a request parameter present.
>>>>>This works out the same way with one little caveat. Some day someone is
>>>>>going to do
>>>>>
>>>>><jx:if test="${user.role == 'admin'}">
>>>>><ft:widget id="bigDangerousButton"/>
>>>>></jx:if>
>>>>>
>>>>>and will be in for a mighty surprise.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I don't follow you here can you give some more details for that scenario.
>>>>
>>>>
>>>>
>>>>
>>>What I meant was that in the scenario above a malicious user can add a
>>>request parameter "bigDangerousButton" to the POST and it will be
>>>processed by the population mechanism (firing off button events) even if
>>>the user has role "user" in the example above. I think this would
>>>actually be quite a common usecase having one form template rendered
>>>differently depending on what type of user access it. The problem is
>>>that a population mechanism without knowledge of what has been rendered
>>>cannot make decisions about which widgets are eligible for population.
>>>
>>>
>>>
>>>
>>On that particular point, it seems to me *especially dangerous* to let
>>the template decide what what widgets are to be displayed depending on
>>user roles.
>>
>>ACL is an application-level concern, and *must* be handled by the
>>controller and/or the application logic. That's what widget states
>>allow: by setting the "bigDangerousButton" state to invisible, you don't
>>even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will
>>simply render nothing if the widget's state is invisible.
>>
>>
>
>The problem with this approach is that normally (I would think at least)
>widget states will be changed in a manner orthogonal to the widget
>hierarchy. The widgets being hidden will be all over the form rather
>than under one single fd:struct that can be switched on/off.
>
>Take the current project I'm working on. I have a Taxon (4 subclasses)
>which contains a list of Specifiers (3 subclasses) which contains a list
>of Tokens (4 subclasses). Each of the subclasses are rendered
>differently depending on class and whether they are edited or viewed.
>The user can also choose whether to view/edit the whole hierarchy at
>once or only parts of it.
>
>To do this I use one jxmacro for each subclass. The macro renders form
>fields if ${edit == 'true'} or text otherwise. It would be a nightmare
>trying to do this with CForm as I would have to walk around the entire
>widget tree setting widget states when switching between editing and
>viewing.
>
>
Looks to me this is the perfect use case for union and class widgets in
CForms. I had similar use-cases for an IDE-like webapp, and these
widgets made wonders.
Also, have you looked at the "form gui" and "swan" samples where they
are heavily showcased?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
>
> >On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> >
> >
>
> <snip/>
>
> >>>Another way of doing the same, which I think was the agreed upon way to
> >>>do it is to populate all widgets that has a request parameter present.
> >>>This works out the same way with one little caveat. Some day someone is
> >>>going to do
> >>>
> >>><jx:if test="${user.role == 'admin'}">
> >>> <ft:widget id="bigDangerousButton"/>
> >>></jx:if>
> >>>
> >>>and will be in for a mighty surprise.
> >>>
> >>>
> >>I don't follow you here can you give some more details for that scenario.
> >>
> >>
> >
> >What I meant was that in the scenario above a malicious user can add a
> >request parameter "bigDangerousButton" to the POST and it will be
> >processed by the population mechanism (firing off button events) even if
> >the user has role "user" in the example above. I think this would
> >actually be quite a common usecase having one form template rendered
> >differently depending on what type of user access it. The problem is
> >that a population mechanism without knowledge of what has been rendered
> >cannot make decisions about which widgets are eligible for population.
> >
> >
>
> On that particular point, it seems to me *especially dangerous* to let
> the template decide what what widgets are to be displayed depending on
> user roles.
>
> ACL is an application-level concern, and *must* be handled by the
> controller and/or the application logic. That's what widget states
> allow: by setting the "bigDangerousButton" state to invisible, you don't
> even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will
> simply render nothing if the widget's state is invisible.
The problem with this approach is that normally (I would think at least)
widget states will be changed in a manner orthogonal to the widget
hierarchy. The widgets being hidden will be all over the form rather
than under one single fd:struct that can be switched on/off.
Take the current project I'm working on. I have a Taxon (4 subclasses)
which contains a list of Specifiers (3 subclasses) which contains a list
of Tokens (4 subclasses). Each of the subclasses are rendered
differently depending on class and whether they are edited or viewed.
The user can also choose whether to view/edit the whole hierarchy at
once or only parts of it.
To do this I use one jxmacro for each subclass. The macro renders form
fields if ${edit == 'true'} or text otherwise. It would be a nightmare
trying to do this with CForm as I would have to walk around the entire
widget tree setting widget states when switching between editing and
viewing.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
>> Jonas Ekstedt wrote:
>
>
> <snip/>
>
>>> What I meant was that in the scenario above a malicious user can add a
>>> request parameter "bigDangerousButton" to the POST and it will be
>>> processed by the population mechanism (firing off button events)
>>> even if
>>> the user has role "user" in the example above. I think this would
>>> actually be quite a common usecase having one form template rendered
>>> differently depending on what type of user access it. The problem is
>>> that a population mechanism without knowledge of what has been rendered
>>> cannot make decisions about which widgets are eligible for population.
>>>
>>
>>
>> On that particular point, it seems to me *especially dangerous* to
>> let the template decide what what widgets are to be displayed
>> depending on user roles.
>>
>> ACL is an application-level concern, and *must* be handled by the
>> controller and/or the application logic. That's what widget states
>> allow: by setting the "bigDangerousButton" state to invisible, you
>> don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
>> will simply render nothing if the widget's state is invisible.
>
>
> I agree about that, ACL is definitelly not a view concern. It should
> be enforced in the business logic and supported in the form model. I
> think widget states is a good way to support ACL in the form model,
> even if I would have preferd to make it declarative rather than
> programatic. One way would be to let the form definition take
> parameters, so that choice (union) can check if e.g. an administrator
> parameter is true and in that case include the "bigDangerousButton" in
> the form model, otherwise not. In this way the the widget would not
> only be invisible for ordinary users, it would be non existent. And
> there would be no risk that faulty event handling code would make it
> visible in some corner case.
Just some RT, but declarative ACL could maybe be achieved through widget
attributes, e.g.
<fd:field id="sensitiveInfo">
<fd:attributes>
<fd:attribute name="acl" value="boss, admin, root"/>
</fd:attributes>
</fd:field>
and then have this information be handled by some kind of on-create
event listener, or some form-level aspects.
Just a RT, though...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-17 at 09:52 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
<snip/>
> > Suppose you have a list of tasks that can be viewed/edited. In
> >edit mode all tasks you have been assigned will show a "Finished"
> >button. In JXTemplate you could do this very easy:
> >
> ><jx:forEach var="task" items="${tasks}">
> > <tr>
> > <td>${task.description}</td>
> > <td>
> > <jx:if test="${edit == 'true' and task.assignedTo == user.id}">
> > <button name="task.${task.id}.finished">Finished</button>
> > </jx:if>
> > </td>
> > </tr>
> ></jx:forEach>
> >
> >The model would of course also check that the user trying to finish a
> >task is indeed the assigned user.
> >
> >In CForm I think it would be very difficult to do something like this.
> >Even if using union widgets.
> >
>
> Unions won't be useful here, as we don't have structure variations, but
> a single widget whose state depends on some model and/or other widget
> values.
>
> >You would have to resort to using flow and iterate through all tasks and enable/disable the buttons individually.
> >
> >
>
> That can be handled automatically in the binding when the form is filled
> with task data.
But what would happen if I reassign a task to myself in the example
above. Then the form would have to be saved and reloaded in order for
the "Finish" button to show up. I fail to see what would be so bad in
using JXTemplate logic to decide which widgets should be shown.
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Tue, 2004-11-16 at 09:39 +0100, Sylvain Wallez wrote:
>
>
>>Jonas Ekstedt wrote:
>>
>>
>>
>>>On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
>>>
>>>
>>>
>>>
>>>>Sylvain Wallez wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Jonas Ekstedt wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>><snip/>
>>>>
>>>>
>>>>
>>>>
>>>>>>What I meant was that in the scenario above a malicious user can add a
>>>>>>request parameter "bigDangerousButton" to the POST and it will be
>>>>>>processed by the population mechanism (firing off button events) even if
>>>>>>the user has role "user" in the example above. I think this would
>>>>>>actually be quite a common usecase having one form template rendered
>>>>>>differently depending on what type of user access it. The problem is
>>>>>>that a population mechanism without knowledge of what has been rendered
>>>>>>cannot make decisions about which widgets are eligible for population.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>On that particular point, it seems to me *especially dangerous* to let
>>>>>the template decide what what widgets are to be displayed depending on
>>>>>user roles.
>>>>>
>>>>>ACL is an application-level concern, and *must* be handled by the
>>>>>controller and/or the application logic. That's what widget states
>>>>>allow: by setting the "bigDangerousButton" state to invisible, you
>>>>>don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
>>>>>will simply render nothing if the widget's state is invisible.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I agree about that, ACL is definitelly not a view concern. It should be
>>>>enforced in the business logic and supported in the form model.
>>>>
>>>>
>>>>
>>>>
>>>In my view there are three aspects to ACL. Taking the example of a form
>>>that can be viewed or edit:
>>>
>>>* Are we in view or edit mode (a controller concern)
>>>* Should I show a field widget or simple text (a view concern)
>>>
>>>
>>>
>>>
>>What's the difference with the first aspect?
>>
>>
>
>What I meant was that the controller makes the decision about what state
>we're in (eg setting an edit flag to true or false). The view will
>contain the logic to actually implement that decision (using jx logic
>for example).
>
>
By "implementing that decision", do you mean that it's the view's
responsibility to render a widget according to its state? That's for
sure, and in CForms this is implemented (and factorized) in the
rendering stylesheets rather than in each page template.
>>>* Should I set this value (a model concern)
>>>
>>>
>> From a from framework POV, this aspect should be "should I accept user
>>input for this value", as the domain model shouldn't care about form
>>handling.
>>
>>
>
>True
>
>
>
>>>Ideally all the controller would have to do is:
>>>if (user.role == "admin")
>>> cocoon.sendPage("page", {mode: "edit");
>>>else
>>> cocoon.sendPage("page", {mode: "view");
>>>
>>>
>>>
>>>
>>And what about:
>>
>>if (user.role == "admin")
>> form.setState("disabled"); // or "output" to show only text
>>else
>> form.setState("active");
>>
>>cocoon.sendPage("page");
>>
>>
>
>Am I right in thinking that form.setState("active") would recursively
>activate all child widgets?
>
States are an ordered enumeration: invisible < disabled < active. The
actual state of a widget is the strictest one between its own state and
the state of its parent. That means that form.setState("disable") will
disable the whole form whereas form.setState("active") will not activate
widgets whose own state is disables. See AbstractWidget.getCombinedState().
>In that case I think it would be too coarse-
>grained. Suppose you have a list of tasks that can be viewed/edited. In
>edit mode all tasks you have been assigned will show a "Finished"
>button. In JXTemplate you could do this very easy:
>
><jx:forEach var="task" items="${tasks}">
> <tr>
> <td>${task.description}</td>
> <td>
> <jx:if test="${edit == 'true' and task.assignedTo == user.id}">
> <button name="task.${task.id}.finished">Finished</button>
> </jx:if>
> </td>
> </tr>
></jx:forEach>
>
>The model would of course also check that the user trying to finish a
>task is indeed the assigned user.
>
>In CForm I think it would be very difficult to do something like this.
>Even if using union widgets.
>
Unions won't be useful here, as we don't have structure variations, but
a single widget whose state depends on some model and/or other widget
values.
>You would have to resort to using flow and iterate through all tasks and enable/disable the buttons individually.
>
>
That can be handled automatically in the binding when the form is filled
with task data.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-16 at 09:39 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
>
> >On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
> >
> >
> >>Sylvain Wallez wrote:
> >>
> >>
> >>>Jonas Ekstedt wrote:
> >>>
> >>>
> >><snip/>
> >>
> >>
> >>>>What I meant was that in the scenario above a malicious user can add a
> >>>>request parameter "bigDangerousButton" to the POST and it will be
> >>>>processed by the population mechanism (firing off button events) even if
> >>>>the user has role "user" in the example above. I think this would
> >>>>actually be quite a common usecase having one form template rendered
> >>>>differently depending on what type of user access it. The problem is
> >>>>that a population mechanism without knowledge of what has been rendered
> >>>>cannot make decisions about which widgets are eligible for population.
> >>>>
> >>>>
> >>>>
> >>>On that particular point, it seems to me *especially dangerous* to let
> >>>the template decide what what widgets are to be displayed depending on
> >>>user roles.
> >>>
> >>>ACL is an application-level concern, and *must* be handled by the
> >>>controller and/or the application logic. That's what widget states
> >>>allow: by setting the "bigDangerousButton" state to invisible, you
> >>>don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
> >>>will simply render nothing if the widget's state is invisible.
> >>>
> >>>
> >>I agree about that, ACL is definitelly not a view concern. It should be
> >>enforced in the business logic and supported in the form model.
> >>
> >>
> >
> >In my view there are three aspects to ACL. Taking the example of a form
> >that can be viewed or edit:
> >
> >* Are we in view or edit mode (a controller concern)
> >* Should I show a field widget or simple text (a view concern)
> >
> >
>
> What's the difference with the first aspect?
What I meant was that the controller makes the decision about what state
we're in (eg setting an edit flag to true or false). The view will
contain the logic to actually implement that decision (using jx logic
for example).
>
> >* Should I set this value (a model concern)
> >
> >
>
> From a from framework POV, this aspect should be "should I accept user
> input for this value", as the domain model shouldn't care about form
> handling.
True
> >Ideally all the controller would have to do is:
> >if (user.role == "admin")
> > cocoon.sendPage("page", {mode: "edit");
> >else
> > cocoon.sendPage("page", {mode: "view");
> >
> >
>
> And what about:
>
> if (user.role == "admin")
> form.setState("disabled"); // or "output" to show only text
> else
> form.setState("active");
>
> cocoon.sendPage("page");
Am I right in thinking that form.setState("active") would recursively
activate all child widgets? In that case I think it would be too coarse-
grained. Suppose you have a list of tasks that can be viewed/edited. In
edit mode all tasks you have been assigned will show a "Finished"
button. In JXTemplate you could do this very easy:
<jx:forEach var="task" items="${tasks}">
<tr>
<td>${task.description}</td>
<td>
<jx:if test="${edit == 'true' and task.assignedTo == user.id}">
<button name="task.${task.id}.finished">Finished</button>
</jx:if>
</td>
</tr>
</jx:forEach>
The model would of course also check that the user trying to finish a
task is indeed the assigned user.
In CForm I think it would be very difficult to do something like this.
Even if using union widgets. You would have to resort to using flow and
iterate through all tasks and enable/disable the buttons individually.
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
>
>
>>Sylvain Wallez wrote:
>>
>>
>>>Jonas Ekstedt wrote:
>>>
>>>
>><snip/>
>>
>>
>>>>What I meant was that in the scenario above a malicious user can add a
>>>>request parameter "bigDangerousButton" to the POST and it will be
>>>>processed by the population mechanism (firing off button events) even if
>>>>the user has role "user" in the example above. I think this would
>>>>actually be quite a common usecase having one form template rendered
>>>>differently depending on what type of user access it. The problem is
>>>>that a population mechanism without knowledge of what has been rendered
>>>>cannot make decisions about which widgets are eligible for population.
>>>>
>>>>
>>>>
>>>On that particular point, it seems to me *especially dangerous* to let
>>>the template decide what what widgets are to be displayed depending on
>>>user roles.
>>>
>>>ACL is an application-level concern, and *must* be handled by the
>>>controller and/or the application logic. That's what widget states
>>>allow: by setting the "bigDangerousButton" state to invisible, you
>>>don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
>>>will simply render nothing if the widget's state is invisible.
>>>
>>>
>>I agree about that, ACL is definitelly not a view concern. It should be
>>enforced in the business logic and supported in the form model.
>>
>>
>
>In my view there are three aspects to ACL. Taking the example of a form
>that can be viewed or edit:
>
>* Are we in view or edit mode (a controller concern)
>* Should I show a field widget or simple text (a view concern)
>
>
What's the difference with the first aspect?
>* Should I set this value (a model concern)
>
>
From a from framework POV, this aspect should be "should I accept user
input for this value", as the domain model shouldn't care about form
handling.
>Ideally all the controller would have to do is:
>if (user.role == "admin")
> cocoon.sendPage("page", {mode: "edit");
>else
> cocoon.sendPage("page", {mode: "view");
>
>
And what about:
if (user.role == "admin")
form.setState("disabled"); // or "output" to show only text
else
form.setState("active");
cocoon.sendPage("page");
>The view would do:
><jx:choose>
> <jx:when test="{mode == 'edit'}">
> <field name="name"/>
> </jx:when>
> <jx:otherwise>
> ${name}
> </jx:otherwise>
></jx:choose>
>
>
And the view would do:
<ft:widget id="name"/>
>And the model would do:
>public void setName(String name, User user) {
> if (user.getRole().equals("admin"))
> this.name = name;
> else
> throw SomeException();
>}
>
>
Yup.
>Alternatively you could have your beans wrapped in some ACLModel that
>enforces the ACL policies.
>
>
Yup. Or AOP-driven ACLs.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
> > Jonas Ekstedt wrote:
>
> <snip/>
>
> >> What I meant was that in the scenario above a malicious user can add a
> >> request parameter "bigDangerousButton" to the POST and it will be
> >> processed by the population mechanism (firing off button events) even if
> >> the user has role "user" in the example above. I think this would
> >> actually be quite a common usecase having one form template rendered
> >> differently depending on what type of user access it. The problem is
> >> that a population mechanism without knowledge of what has been rendered
> >> cannot make decisions about which widgets are eligible for population.
> >>
> >
> > On that particular point, it seems to me *especially dangerous* to let
> > the template decide what what widgets are to be displayed depending on
> > user roles.
> >
> > ACL is an application-level concern, and *must* be handled by the
> > controller and/or the application logic. That's what widget states
> > allow: by setting the "bigDangerousButton" state to invisible, you
> > don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
> > will simply render nothing if the widget's state is invisible.
>
> I agree about that, ACL is definitelly not a view concern. It should be
> enforced in the business logic and supported in the form model.
In my view there are three aspects to ACL. Taking the example of a form
that can be viewed or edit:
* Are we in view or edit mode (a controller concern)
* Should I show a field widget or simple text (a view concern)
* Should I set this value (a model concern)
Ideally all the controller would have to do is:
if (user.role == "admin")
cocoon.sendPage("page", {mode: "edit");
else
cocoon.sendPage("page", {mode: "view");
The view would do:
<jx:choose>
<jx:when test="{mode == 'edit'}">
<field name="name"/>
</jx:when>
<jx:otherwise>
${name}
</jx:otherwise>
</jx:choose>
And the model would do:
public void setName(String name, User user) {
if (user.getRole().equals("admin"))
this.name = name;
else
throw SomeException();
}
Alternatively you could have your beans wrapped in some ACLModel that
enforces the ACL policies.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
<snip/>
>> What I meant was that in the scenario above a malicious user can add a
>> request parameter "bigDangerousButton" to the POST and it will be
>> processed by the population mechanism (firing off button events) even if
>> the user has role "user" in the example above. I think this would
>> actually be quite a common usecase having one form template rendered
>> differently depending on what type of user access it. The problem is
>> that a population mechanism without knowledge of what has been rendered
>> cannot make decisions about which widgets are eligible for population.
>>
>
> On that particular point, it seems to me *especially dangerous* to let
> the template decide what what widgets are to be displayed depending on
> user roles.
>
> ACL is an application-level concern, and *must* be handled by the
> controller and/or the application logic. That's what widget states
> allow: by setting the "bigDangerousButton" state to invisible, you
> don't even need the <jx:if>. The <ft:widget id="bigDangerousButton"/>
> will simply render nothing if the widget's state is invisible.
I agree about that, ACL is definitelly not a view concern. It should be
enforced in the business logic and supported in the form model. I think
widget states is a good way to support ACL in the form model, even if I
would have preferd to make it declarative rather than programatic. One
way would be to let the form definition take parameters, so that choice
(union) can check if e.g. an administrator parameter is true and in that
case include the "bigDangerousButton" in the form model, otherwise not.
In this way the the widget would not only be invisible for ordinary
users, it would be non existent. And there would be no risk that faulty
event handling code would make it visible in some corner case.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
>
>
<snip/>
>>>Another way of doing the same, which I think was the agreed upon way to
>>>do it is to populate all widgets that has a request parameter present.
>>>This works out the same way with one little caveat. Some day someone is
>>>going to do
>>>
>>><jx:if test="${user.role == 'admin'}">
>>> <ft:widget id="bigDangerousButton"/>
>>></jx:if>
>>>
>>>and will be in for a mighty surprise.
>>>
>>>
>>I don't follow you here can you give some more details for that scenario.
>>
>>
>
>What I meant was that in the scenario above a malicious user can add a
>request parameter "bigDangerousButton" to the POST and it will be
>processed by the population mechanism (firing off button events) even if
>the user has role "user" in the example above. I think this would
>actually be quite a common usecase having one form template rendered
>differently depending on what type of user access it. The problem is
>that a population mechanism without knowledge of what has been rendered
>cannot make decisions about which widgets are eligible for population.
>
>
On that particular point, it seems to me *especially dangerous* to let
the template decide what what widgets are to be displayed depending on
user roles.
ACL is an application-level concern, and *must* be handled by the
controller and/or the application logic. That's what widget states
allow: by setting the "bigDangerousButton" state to invisible, you don't
even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will
simply render nothing if the widget's state is invisible.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> We use bugzilla for new ideas and project planning also, not only as a
> bug db. Prefix the subject line with [Patch] and mark your patch as an
> enhancement. Of course you can new ideas and half finished stuff there
> as long as you describe what it is. It would be very bad if we didn't
> have a structured way for non committers to contribute ideas.
I filed an enhancement bug as you suggested.
> >Another way of doing the same, which I think was the agreed upon way to
> >do it is to populate all widgets that has a request parameter present.
> >This works out the same way with one little caveat. Some day someone is
> >going to do
> >
> ><jx:if test="${user.role == 'admin'}">
> > <ft:widget id="bigDangerousButton"/>
> ></jx:if>
> >
> >and will be in for a mighty surprise.
> >
> I don't follow you here can you give some more details for that scenario.
>
What I meant was that in the scenario above a malicious user can add a
request parameter "bigDangerousButton" to the POST and it will be
processed by the population mechanism (firing off button events) even if
the user has role "user" in the example above. I think this would
actually be quite a common usecase having one form template rendered
differently depending on what type of user access it. The problem is
that a population mechanism without knowledge of what has been rendered
cannot make decisions about which widgets are eligible for population.
> > On the other hand, as has been
> >pointed out previously collecting widgets in a something like a
> >WidgetPopulator won't work unless you use flow.
> >
> >
> >
> Why wouldn't it, can you give a pointer.
There are two stages in the life of the WidgetPopulator. During the
first request it is used to register which widgets were rendered. Then
in the second request, when the form is submitted, the same
WidgetPopulator instance is used to determine which widgets should be
populated.
I don't really know how to do this unless flow is used as you must use
the same WidgetPopulator instance in two subsequent requests. One
alternative would be to store it in the Session but then there would be
problems if two instances of the form is run at the same time.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Sat, 2004-11-06 at 16:13 +0100, Daniel Fagerstrom wrote:
>
>
>>Please submit your patch to Bugzilla so that it doesn't get lost among
>>all the mails. See http://wiki.apache.org/cocoon/ProjectManagement for
>>instructions. It is also good to have a Bugzilla entry so that you can
>>add refinements to your code there.
>>
>>
>
>I have wondered a bit about Bugzilla. Is it only supposed to be bug
>fixes that appear there or are ideas okay as well. I thought it might
>clutter the bug database if I introduced half finished stuff there.
>
>
We use bugzilla for new ideas and project planning also, not only as a
bug db. Prefix the subject line with [Patch] and mark your patch as an
enhancement. Of course you can new ideas and half finished stuff there
as long as you describe what it is. It would be very bad if we didn't
have a structured way for non committers to contribute ideas.
>>>Instead of the original RequestProcessor there is instead a
>>>WidgetPopulator. It works similar in that it is added as an attribute to
>>>the request in Form.js.
>>>
>>>
>>Why is it added to the Request, wouldn't it be more natural to bind it
>>to a variable in the flowscript instead?
>>
>>
>True
>
>
Never mind, it made sense when I read the code.
>>But as long as it is bounded to the widget hierarchy so that the widget
>>hierarchy cannot be replaced by another model, does the widget populator
>>by us something in its current form?
>>
>>
>
>Well I think it is useful to some extent. With the WidgetPopulator you
>can use JXTemplate to hide widgets instead of having to do it in flow
>setting individual widget states. This way none of the proposed logic
>widgets are needed (choose, when etc.).
>
>
AFAIR, choose/when is a replacement for union. Union is part of the type
definition, while widget states for hiding and skip validation of parts
of a form in a multi page form context is a presentation concern. I
agree with that the WidgetPopulator is a convinient way to handle
validation in a multi page form context. Possibly it could be to set the
widget states for handling hiding and validation thru that mechanism, I
have no idea how, though. And as I have described earlier in this thread
I prefer the widget hierarchy to be a passive data structure that is set
from a request processor.
>Another way of doing the same, which I think was the agreed upon way to
>do it is to populate all widgets that has a request parameter present.
>This works out the same way with one little caveat. Some day someone is
>going to do
>
><jx:if test="${user.role == 'admin'}">
> <ft:widget id="bigDangerousButton"/>
></jx:if>
>
>and will be in for a mighty surprise.
>
I don't follow you here can you give some more details for that scenario.
> On the other hand, as has been
>pointed out previously collecting widgets in a something like a
>WidgetPopulator won't work unless you use flow.
>
>
>
Why wouldn't it, can you give a pointer.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Sat, 2004-11-06 at 16:13 +0100, Daniel Fagerstrom wrote:
> Please submit your patch to Bugzilla so that it doesn't get lost among
> all the mails. See http://wiki.apache.org/cocoon/ProjectManagement for
> instructions. It is also good to have a Bugzilla entry so that you can
> add refinements to your code there.
I have wondered a bit about Bugzilla. Is it only supposed to be bug
fixes that appear there or are ideas okay as well. I thought it might
clutter the bug database if I introduced half finished stuff there.
> > Instead of the original RequestProcessor there is instead a
> > WidgetPopulator. It works similar in that it is added as an attribute to
> > the request in Form.js.
>
> Why is it added to the Request, wouldn't it be more natural to bind it
> to a variable in the flowscript instead?
True
> But as long as it is bounded to the widget hierarchy so that the widget
> hierarchy cannot be replaced by another model, does the widget populator
> by us something in its current form?
Well I think it is useful to some extent. With the WidgetPopulator you
can use JXTemplate to hide widgets instead of having to do it in flow
setting individual widget states. This way none of the proposed logic
widgets are needed (choose, when etc.).
Another way of doing the same, which I think was the agreed upon way to
do it is to populate all widgets that has a request parameter present.
This works out the same way with one little caveat. Some day someone is
going to do
<jx:if test="${user.role == 'admin'}">
<ft:widget id="bigDangerousButton"/>
</jx:if>
and will be in for a mighty surprise. On the other hand, as has been
pointed out previously collecting widgets in a something like a
WidgetPopulator won't work unless you use flow.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
I'll give some short comments now. Hope to find time to give a more
detailed view about multiform handling and other stuff later.
Jonas Ekstedt wrote:
<snip/>
> I tried to implement a RequestProcessor for CForms just to see if it was
> doable.
Cool!
> It doesn't yet work quite the way you envision with converters
> and renderers as I wanted the change to be as minimal as possible.
Seems reasonable, it is much better to work in steps, than trying to
introduce everything at once. Easier to get feedback that way also.
Think that the rendering/convertion stuff could need some more thought
before implementation also.
> Instead it uses some of the existing widget methods for population. I've
> attached two patches if you want to try it out (I'm a bit of a novice
> with subversion and creating patches so they might not work).
Please submit your patch to Bugzilla so that it doesn't get lost among
all the mails. See http://wiki.apache.org/cocoon/ProjectManagement for
instructions. It is also good to have a Bugzilla entry so that you can
add refinements to your code there.
Your subversion patches seemed to work except for that I had to add the
directory samples/widgetpopulation and add it in subversion to make it
possible to apply the samples patch.
> As far as
> I can tell the changes are backwards compatible (the other samples seems
> to work anyway).
>
> Instead of the original RequestProcessor there is instead a
> WidgetPopulator. It works similar in that it is added as an attribute to
> the request in Form.js.
Why is it added to the Request, wouldn't it be more natural to bind it
to a variable in the flowscript instead?
> Then during rendering, each widget that is
> rendered will try to register itself on this WidgetPopulator (this is
> done in jx-macros.xml). Currently only widgets of type Action,
> BooleanField, Field, MultiValueField, RowAction, Submit and Upload will
> be registered. I don't really know how to handle AggregateField and
> haven't tested if it suffices to register it's child widgets only.
RT: could this mechanism be used to automatically set the widget states
for multi page forms?
IIRC your main reason for the WidgetPopulator with render time
registration, was to get safe model loading without having to write an
excplit form definition.
But as long as it is bounded to the widget hierarchy so that the widget
hierarchy cannot be replaced by another model, does the widget populator
by us something in its current form?
> After the form has been submitted the list of registered widgets is sent
> to Form.process(). Then instead of recursively populating all widgets
> the form widget will iterate through the list of registered widgets and
> call readFromRequest() on each.
>
> Currently the WidgetPopulator is simply a holder of widgets that should
> be populated and it is the Form that does the population. I did it this
> way because the CForm code was a bit overwhelming and it was hard to get
> a grip on what side effects would occur if population was lifted out of
> the Form. Preferably population should be done in the WidgetPopulator.
Agree that CForms is a little bit overwhelming. You can find an example
of how to populate a widget from SAX input here:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/util/XMLAdapter.java?view=auto
I don't know what effect lifting out the population would have on event
handling and validation. Hopefully someone with more knowledge about the
CForm life cycle read this and explains.
You can find some info about the CForm life cycle here:
http://wiki.apache.org/cocoon/WoodyRefactoring
Thanks for the patch!
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Thu, 2004-11-04 at 23:42 +0100, Daniel Fagerstrom wrote:
> >>I prefer the request processor idea to the current form population where
> >>each widget reads it data from the request object. The current scheme
> >>makes CForms unecesarily bound to the request parameter model of input
> >>data. With a request processor that is reponsible to write input data
> >>into the form model, it would be easy to plug in a different request
> >>processor if one gets xml input from a browser that implements XForms, e.g.
> >
> > I think it would be quite easy to make this change to CForm.
>
> So do I, although I havn't studied the details in CForms for a while. I
> guess it can be done in a completely back compatible way. A request
> processor, a convertor/renderer and a view adapter needs to be written.
> Then one just don't use the readFromRequest and generateSaxfragment any
> more. There might be subtilities in the state sequence within widgets
> that complicates thins though.
I tried to implement a RequestProcessor for CForms just to see if it was
doable. It doesn't yet work quite the way you envision with converters
and renderers as I wanted the change to be as minimal as possible.
Instead it uses some of the existing widget methods for population. I've
attached two patches if you want to try it out (I'm a bit of a novice
with subversion and creating patches so they might not work). As far as
I can tell the changes are backwards compatible (the other samples seems
to work anyway).
Instead of the original RequestProcessor there is instead a
WidgetPopulator. It works similar in that it is added as an attribute to
the request in Form.js. Then during rendering, each widget that is
rendered will try to register itself on this WidgetPopulator (this is
done in jx-macros.xml). Currently only widgets of type Action,
BooleanField, Field, MultiValueField, RowAction, Submit and Upload will
be registered. I don't really know how to handle AggregateField and
haven't tested if it suffices to register it's child widgets only.
After the form has been submitted the list of registered widgets is sent
to Form.process(). Then instead of recursively populating all widgets
the form widget will iterate through the list of registered widgets and
call readFromRequest() on each.
Currently the WidgetPopulator is simply a holder of widgets that should
be populated and it is the Form that does the population. I did it this
way because the CForm code was a bit overwhelming and it was hard to get
a grip on what side effects would occur if population was lifted out of
the Form. Preferably population should be done in the WidgetPopulator.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
> On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
<snip/>
>>In some cases like when you
>>can build lists or trees in the user interface, a more traversal based
>>interface is needed.
>
> I agree that I haven't really thought this issue through thoroughly. In
> the widget framework there is a "public int size(String path)" method
> that returns the size of whatever object is present at that path. But
> there could certainly be more stuff thrown in such as support for
> pointers similar to JXPath that can run around in your model data.
Yes, a tree traversal inteface is needed maybe something like:
String getValue(String path);
Pointer getPointer(String path);
Iterator getIterator(String path);
>>Also, like everyone else that has commented your proposal, I think that
>>it often is a bad idea to write directly to your model. Even if you are
>>able to solve the security problems, the model will still need to be
>>able to store partially invalid input data and missing data. IMO it is
>>better SoC to have a form model in front of the real model. This
>>decreases the complexity of the model as it always can get data in a
>>more transactinal way in complete chunks.
>
> Protecting the application object is partly what the Model interface is
> all about. In the getValue/setValue functions you can implement any
> measures to protect the application object you'd like. The point is that
> the user should decide what type of shielding should be used.
>
> Eg. the project I'm working on is dependant on letting the view access
> derived values from the bean model. That means I need to populate the
> beans directly. I do not really care if the beans are inconsistent as I
> won't hibernate them if they are (in a sense the database is my
> "application object" that I need to shield). So in my case it makes
> sense to operate directly on the application object.
>
> However, as a different example, should I start using beans with
> properties like ints or Dates then I would choose some other strategy as
> I need to be able to save values even when they are not convertible. In
> this case the wrapping model could store illegal values in a separate
> map. getValue() would then return values from the map if they exist or
> from the bean otherwise.
>
> The second approach is similar to how CForm widgets works. What I think
> is the benefit of the Model interface is that it is up to the user to
> decide what type of shielding should take place.
I agree that CForms is a little bit monolitic and that it would be god
if we could find a strict decomposition of the different involved
concern areas. Then we could have well defined and hopefully small
interfaces between the parts and make it possible for webapp developers
to reuse parts of it.
My curent view of the involved concern areas is something like:
+------------------+ +-----------+ +-------+ +----------+
| RequestProcessor |--->| Convertor | | Form | | Business |
+------------------+ +-----------+<-->| |<-->| |
| Template Engine |<---| Renderer | | Model | | Model |
+------------------+ +-----------+ +-------+ +----------+
Of course there is a controller as well, but that is not the subject for
this discussion. Compared to the usuall MVC pattern we can see that the
model is split in a form model and a business model. The binding step
between the form and business model should maybe also have an own box,
but then the image didn't fit within the 71 charachters ;). We also have
a convertor/renderer step. Compared to CForms curent state the request
processor, and convertor/renderer has different positions.
We folow the data from request to respons. The request processor parses
the request object or the xml input or what you have. And write this to
something like the model interface you proposed:
void setValue(String path, String value) {
Datatype type = formModel.getDatatype(path);
Object obj = convertor.convert(value, type, locale);
formModel.setValue(path, obj);
}
We could maybe call this part a view adapter. It doesn't contain any
data and is only an adapter that perform the conversion/rendering before
writing to/reading from the form model.
For the form model <-> business model communication everything is like
it use to be. With the adition that for some kinds of business model
implementations, like DOM-trees, XML DBs and RDBs, it might be usefull
with a convertor/renderer step also. So that you don't have to use the
same data type conversions in the binding each time you use a certain
data type.
In the last step the template engine reads from the view adapter thru a
tree based interface, like the one I proposed in the begining.
So in this model the view adapter gives read and write access to an
untyped tree and the form model is a typed tree that also contain
validation and event handling.
---o0o---
Given that we can find good interfaces between the different steps. You
and other Cocoon webap developers can resuse parts of the form framework
to your own liking. If you don't want the split in business and form
model in a certain application you can still use the rest of the framework.
>>I prefer the request processor idea to the current form population where
>>each widget reads it data from the request object. The current scheme
>>makes CForms unecesarily bound to the request parameter model of input
>>data. With a request processor that is reponsible to write input data
>>into the form model, it would be easy to plug in a different request
>>processor if one gets xml input from a browser that implements XForms, e.g.
>
> I think it would be quite easy to make this change to CForm.
So do I, although I havn't studied the details in CForms for a while. I
guess it can be done in a completely back compatible way. A request
processor, a convertor/renderer and a view adapter needs to be written.
Then one just don't use the readFromRequest and generateSaxfragment any
more. There might be subtilities in the state sequence within widgets
that complicates thins though.
WD[Y|O]T
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
> Jonas Ekstedt wrote:
> >
> > public interface Model {
> > public String getValue(String path);
> > public void setValue(String path, String value);
> > }
> >
> IMO, such an interface is a good starting point, although it needs
> exceptions for cases when conversion fails.
True
> In some cases like when you
> can build lists or trees in the user interface, a more traversal based
> interface is needed.
I agree that I haven't really thought this issue through thoroughly. In
the widget framework there is a "public int size(String path)" method
that returns the size of whatever object is present at that path. But
there could certainly be more stuff thrown in such as support for
pointers similar to JXPath that can run around in your model data.
> Also, like everyone else that has commented your proposal, I think that
> it often is a bad idea to write directly to your model. Even if you are
> able to solve the security problems, the model will still need to be
> able to store partially invalid input data and missing data. IMO it is
> better SoC to have a form model in front of the real model. This
> decreases the complexity of the model as it always can get data in a
> more transactinal way in complete chunks.
Protecting the application object is partly what the Model interface is
all about. In the getValue/setValue functions you can implement any
measures to protect the application object you'd like. The point is that
the user should decide what type of shielding should be used.
Eg. the project I'm working on is dependant on letting the view access
derived values from the bean model. That means I need to populate the
beans directly. I do not really care if the beans are inconsistent as I
won't hibernate them if they are (in a sense the database is my
"application object" that I need to shield). So in my case it makes
sense to operate directly on the application object.
However, as a different example, should I start using beans with
properties like ints or Dates then I would choose some other strategy as
I need to be able to save values even when they are not convertible. In
this case the wrapping model could store illegal values in a separate
map. getValue() would then return values from the map if they exist or
from the bean otherwise.
The second approach is similar to how CForm widgets works. What I think
is the benefit of the Model interface is that it is up to the user to
decide what type of shielding should take place.
> I prefer the request processor idea to the current form population where
> each widget reads it data from the request object. The current scheme
> makes CForms unecesarily bound to the request parameter model of input
> data. With a request processor that is reponsible to write input data
> into the form model, it would be easy to plug in a different request
> processor if one gets xml input from a browser that implements XForms, e.g.
I think it would be quite easy to make this change to CForm.
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
> On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:
>>Ok, the idea is as follows: we have a converter component, that is like
>>the renderer component above, but bidirectional. I.e. both rendering:
>>data type -> displayable string and input conversion: input string ->
>>data type. The converter is configured in the same way as described for
>>the renderer above.
>
> I've been working along the same line [1] (it's about a widget framework
> but contains elements that are relevant to your idea as well). The idea
> is that data is wrapped by a model that works directly on my data but
> that can perform any conversions, validations etc through its
> getValue/setValue functions:
>
> public interface Model {
> public String getValue(String path);
> public void setValue(String path, String value);
> }
>
IMO, such an interface is a good starting point, although it needs
exceptions for cases when conversion fails. In some cases like when you
can build lists or trees in the user interface, a more traversal based
interface is needed.
Also, like everyone else that has commented your proposal, I think that
it often is a bad idea to write directly to your model. Even if you are
able to solve the security problems, the model will still need to be
able to store partially invalid input data and missing data. IMO it is
better SoC to have a form model in front of the real model. This
decreases the complexity of the model as it always can get data in a
more transactinal way in complete chunks.
I prefer the request processor idea to the current form population where
each widget reads it data from the request object. The current scheme
makes CForms unecesarily bound to the request parameter model of input
data. With a request processor that is reponsible to write input data
into the form model, it would be easy to plug in a different request
processor if one gets xml input from a browser that implements XForms, e.g.
> For example if my data is a bean containing a Date then a
> ConvertingBeanModel wrapping my bean would have a getValue function
> performing the Date->String conversion (according to whatever locale is
> chosen). And vice versa with setValue. The benefit with having an
> abstract view of the model would be that you can implement any type of
> conversion in the setValue/getValue functions. You could have a generic
> set of conversions for the basic types as well as special conversions
> unique to your application. Eg. if your underlying data is a resultset
> then you can convert values to SQL types rather than java types.
If we translate this to the CForms case, generic sets of convertors,
would not only be useful for rendering and handling input to the widget
hierarchy, they would be useful in the binding step also.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors (was:
Templating Engine - Next steps?)
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote:
> Ok, the idea is as follows: we have a converter component, that is like
> the renderer component above, but bidirectional. I.e. both rendering:
> data type -> displayable string and input conversion: input string ->
> data type. The converter is configured in the same way as described for
> the renderer above.
>
I've been working along the same line [1] (it's about a widget framework
but contains elements that are relevant to your idea as well). The idea
is that data is wrapped by a model that works directly on my data but
that can perform any conversions, validations etc through its
getValue/setValue functions:
public interface Model {
public String getValue(String path);
public void setValue(String path, String value);
}
For example if my data is a bean containing a Date then a
ConvertingBeanModel wrapping my bean would have a getValue function
performing the Date->String conversion (according to whatever locale is
chosen). And vice versa with setValue. The benefit with having an
abstract view of the model would be that you can implement any type of
conversion in the setValue/getValue functions. You could have a generic
set of conversions for the basic types as well as special conversions
unique to your application. Eg. if your underlying data is a resultset
then you can convert values to SQL types rather than java types.
[1] http://www.mail-archive.com/dev@cocoon.apache.org/msg23293.html
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote:
>
>
>>>If I would be able to choose convertors I might decide IN VIEW ITSELF
>>>that that specific model value should be coloured/pretty
>>>printed/rendered according to some specific logic. As long as this
>>>logic has read-only access to model and performs steps to produce some
>>>rendering I do not find it SoC break.
>>>
>>>
>>Seem like an excelent idea to me. I think it could be analog to the use
>>of the class attribute in HTML to give hints to CSS about styling.
>>
>>We could have something like:
>>
>> ${month/balance?class=financialValue}
>>
>>then the finacialValue rule for convertion is used if there is one
>>otherwise the default rule is used. There is no doubt room for
>>improvement of the syntax ;)
>>
>>A functional syntax as Sylvain prpoposed would also be possible:
>>
>> ${convert(month/balance, 'financialValue')}
>>
>>but I percieve the convertor as something that not is part of the
>>expression language (EL). The convertor is applied to the object that is
>>returned from the EL engine, and the default convertor should always be
>>applied on the object, so one shoudn't need to write
>>
>> ${convert(month/balance)}
>>
>>to get the default conversion.
>>
>>
>
>Couldn't the above example be done better with tags instead? For
>example:
>
><mytag:date value="${todaysDate}"/>
>
>This tag could then render as:
>
><mytag:date locale="se" value="2004-11-05"/>
>
>or a financial value could use the tag:
>
><mytag:financial-value value="${month/balance}"/>
>
>that is rendered as:
>
><mytag:financial-value value="-10" currency="SEK" positive="false"/>
>
>This way you avoid complicating the expression language. As I see it the
>only time you're going to do value conversion in your template is when
>outputting values, as opposed to testing values. And if you're merely
>outputting values you can just as easily do conversion with tags
>specifying how to convert your values.
>
>// Jonas
>
>
It could maybe done like that also. The point of puting it in the
expression language (EL) is that if we have a common interface for using
ELs, we can reuse the EL with converter component in all places where we
need an EL in Cocoon without having to reimplement a number of
conversion tags in each case. Tags are also harder to use when you want
a value from your EL whithin an attribute. You could maybe use something
like <xsl:attribute .../> but that is more complicated. IMO it is god if
you get the default conversion without having to write anything extra.
My current view is that we have an converter component that is plugged
in in an adapter in front of the EL engine. The converter component is
configured with a set of default, locale specific and view class
specific rules:
<convertor-set id="default">
<datatype type="java.util.Date">
<convertor type="formating" pattern="MM/dd/yyyy"/>
<convertor locale="nl-BE" type="formating" pattern="dd/MM/yyyy"/>
<convertor locale="fr" type="formating" pattern="dd-MM-yyyy"/>
</datatype>
<datatype type="java.lang.Double">
<convertor type="formating" style="number"/>
<convertor class="financial" type="xml">
<choose>
<when test="$value>=0">
<span class="black">
<convertor type="formating" style="currency"/>
</span>
</when>
<otherwise
<span class="red">
<convertor type="formating" style="currency"/>
</span>
</otherwise>
</choose>
</convertor>
</datatype>
</convertor-set>
WDYT?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Jonas Ekstedt wrote:
>On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote:
>
>
>>>If I would be able to choose convertors I might decide IN VIEW ITSELF
>>>that that specific model value should be coloured/pretty
>>>printed/rendered according to some specific logic. As long as this
>>>logic has read-only access to model and performs steps to produce some
>>>rendering I do not find it SoC break.
>>>
>>>
>>Seem like an excelent idea to me. I think it could be analog to the use
>>of the class attribute in HTML to give hints to CSS about styling.
>>
>>We could have something like:
>>
>> ${month/balance?class=financialValue}
>>
>>then the finacialValue rule for convertion is used if there is one
>>otherwise the default rule is used. There is no doubt room for
>>improvement of the syntax ;)
>>
>>A functional syntax as Sylvain prpoposed would also be possible:
>>
>> ${convert(month/balance, 'financialValue')}
>>
>>but I percieve the convertor as something that not is part of the
>>expression language (EL). The convertor is applied to the object that is
>>returned from the EL engine, and the default convertor should always be
>>applied on the object, so one shoudn't need to write
>>
>> ${convert(month/balance)}
>>
>>to get the default conversion.
>>
>>
>
>Couldn't the above example be done better with tags instead? For
>example:
>
><mytag:date value="${todaysDate}"/>
>
>
Good idea. Actually, I even already used it that way (but just made the
connection now with this discussions) by implementing complex
formattings as JX macros. The use case was presenting an object part of
a tree as the path from the tree root down to the object (i.e. "foo >
bar > baz"), with links on each element. Something I definitely wouldn't
want to do in the controller :-)
So maybe the solution just consists in defining sets of reusable JX macros?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Fri, 2004-11-05 at 14:02 +0100, Daniel Fagerstrom wrote:
> > If I would be able to choose convertors I might decide IN VIEW ITSELF
> > that that specific model value should be coloured/pretty
> > printed/rendered according to some specific logic. As long as this
> > logic has read-only access to model and performs steps to produce some
> > rendering I do not find it SoC break.
>
>
> Seem like an excelent idea to me. I think it could be analog to the use
> of the class attribute in HTML to give hints to CSS about styling.
>
> We could have something like:
>
> ${month/balance?class=financialValue}
>
> then the finacialValue rule for convertion is used if there is one
> otherwise the default rule is used. There is no doubt room for
> improvement of the syntax ;)
>
> A functional syntax as Sylvain prpoposed would also be possible:
>
> ${convert(month/balance, 'financialValue')}
>
> but I percieve the convertor as something that not is part of the
> expression language (EL). The convertor is applied to the object that is
> returned from the EL engine, and the default convertor should always be
> applied on the object, so one shoudn't need to write
>
> ${convert(month/balance)}
>
> to get the default conversion.
Couldn't the above example be done better with tags instead? For
example:
<mytag:date value="${todaysDate}"/>
This tag could then render as:
<mytag:date locale="se" value="2004-11-05"/>
or a financial value could use the tag:
<mytag:financial-value value="${month/balance}"/>
that is rendered as:
<mytag:financial-value value="-10" currency="SEK" positive="false"/>
This way you avoid complicating the expression language. As I see it the
only time you're going to do value conversion in your template is when
outputting values, as opposed to testing values. And if you're merely
outputting values you can just as easily do conversion with tags
specifying how to convert your values.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Seem like an excelent idea to me. I think it could be analog to the use
> of the class attribute in HTML to give hints to CSS about styling.
>
> We could have something like:
>
> ${month/balance?class=financialValue}
The comparison to CSS class is adequate in this situation. Very good idea!
The syntax is a secondary thing but I would also like to denote in the syntax
that the convertor is not the part of the logic really (this would lower the
number of you-are-breaking-SoC-man attacks).
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>>>
>>> What that means is that a convertor should be able to do the
>>> following conversions:
>>> - string+locale --> object : parsing request parameters
>>> - object+locale --> string : producing the value of an input
>>> - object+locale+channel --> xml fragment : producing the output view
>>> for a particular channel (html, wap, fo, etc).
>>>
>>> WDYT?
>>
>>
>>
>> Interesting idea! Question is how do we now that a negative number is
>> a financial entity rather than a temperature, e.g. In the renderer we
>> only know the type of the object to render. Of course if we use more
>> fine grained data types like FinancialNumber and Temperature it would
>> be feasible. But wouldn't that be to let view concerns slip into the
>> model?
>
> Shouldn't user be able to choose a convertor?
Have not thought about it, but it sounds like a good idea. My idea was
mainly about convertor sets, so that you have a list of object+locale
--> string mappings in a convertor configuration file. When you
configure your JXTG (or some or some other template engine), you choose
a default convertor set that is automatically used for all object
accesses. Then you also can configure a set of alternative convertor
sets that you can choose between by explicitly asking for a convertor
set. Using the synatax you propsed earlier: ${elEngine:path} would give
the default convertor set and ${convertorSet:elEngine:path} would give a
named convertor set.
But it might be a good idea to give more fine grained control.
>> Terence Parr sugests that test like "$bloodPressure<120" in the view
>> should be performed in the model and tested in the view like
>> "!$bloodPressureOk". He even says that:
>>
>> Even simple tests that make negative values red should be
>> computed in the model; the right level of abstraction is usually
>> something higher level such as “department x is losing
>> money.”
>
> Still this is very inconvenient if the model is built for you i.e.
> object graph built by hibernate. I would have to make controller
> dependant on view view wants to show.
I agree, that was also what I said in the rest of my mail.
> Right now I just pass one entity to view and do not care if view asks
> for entity fields, entity parent fields, child fields, anything. If I
> have hibernate properly set up the data will be retrieved only when
> needed.
>
> I have project that model have 5-6 depts in parent-child relationship
> like:
> contractor -> surveydefinition -> questioncategory ->
> questiondefinition -> alertcategory -> alertdefinition.
>
> While displaying list of entities on any level I can choose to add
> additional column with link to parent on any level and the only thing
> I have to change is the template. Model remains the same.
>
> If I had to prepare data for view in such detailed manner as Terence
> proposes I would have to:
> - break whole entity tree
> - forget about lazy-loading
> - fetch data on each level separately
> - prepare some kind of DTOs that would apply "view needs" to data
> stored in database
> - build another object graph only for the sake of one view
> and above all:
> - change my model every time I change view template
>
> and still: I do not see any gain if I did that. The code is boasted,
> harder to maintain as more dependencies are introduced and much more
> buggy.
>
> Shouldn't SoC help making the app clearer and more flexible instead of
> making it harder?
Of course it should. The interesting question is of course how to
achieve that. Needing to write specialized adapters for the model data
to make it suitable for the view layer is not such a good idea. Large
amount of type checking code in the view is not a good idea either.
I'll send a link to our discussion to Terence Parr and asks if he would
like to join the discussion.
> If I would be able to choose convertors I might decide IN VIEW ITSELF
> that that specific model value should be coloured/pretty
> printed/rendered according to some specific logic. As long as this
> logic has read-only access to model and performs steps to produce some
> rendering I do not find it SoC break.
Seem like an excelent idea to me. I think it could be analog to the use
of the class attribute in HTML to give hints to CSS about styling.
We could have something like:
${month/balance?class=financialValue}
then the finacialValue rule for convertion is used if there is one
otherwise the default rule is used. There is no doubt room for
improvement of the syntax ;)
A functional syntax as Sylvain prpoposed would also be possible:
${convert(month/balance, 'financialValue')}
but I percieve the convertor as something that not is part of the
expression language (EL). The convertor is applied to the object that is
returned from the EL engine, and the default convertor should always be
applied on the object, so one shoudn't need to write
${convert(month/balance)}
to get the default conversion.
WDYT?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Wed, 2004-11-17 at 10:25 +0100, Daniel Fagerstrom wrote:
><snip/>
>
>
>>I need to review your code a little bit more, then I'll commit the
>>conversion block to the trunk (if no one protest), so that people can
>>start to work on it.
>>
>>
>
>I made a few changes to the conversion block to make it easier to use
>with the template transformer that I wrote about yesterday:
>http://www.mail-archive.com/dev@cocoon.apache.org/msg24473.html
>
>The new version is included in that download. If I remember correctly
>there were no major changes, only details.
>
>
ok
>Cheers Jonas
>
>PS. What are the policies regarding adding large files to bugzilla. I
>have hesitated to add my new template transformer block as it is 0.5 Mb
>(needed to include some jars).
>
>
I don't know if we have any policies about large files, but I would
recomend that you add the source code to Bugzilla and give a description
about where the jars can be downloaded from. There is no identity
controll in Bugzilla so making it a habit to put jars from Bugzilla into
the svn would soner or later attract trojan horse makers.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-17 at 10:25 +0100, Daniel Fagerstrom wrote:
<snip/>
> I need to review your code a little bit more, then I'll commit the
> conversion block to the trunk (if no one protest), so that people can
> start to work on it.
I made a few changes to the conversion block to make it easier to use
with the template transformer that I wrote about yesterday:
http://www.mail-archive.com/dev@cocoon.apache.org/msg24473.html
The new version is included in that download. If I remember correctly
there were no major changes, only details.
Cheers Jonas
PS. What are the policies regarding adding large files to bugzilla. I
have hesitated to add my new template transformer block as it is 0.5 Mb
(needed to include some jars).
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Sun, 2004-11-14 at 22:57 +0100, Daniel Fagerstrom wrote:
>
>
<snip/>
>> Is
>>setId necessary, or are you preparing for dependecy injection?
>>
>>
>
>I think there are cases when supplying a convertor with an id can be
>useful, especially when constructing error messages if conversions
>failed. If you look at the conversion block that I posted to bugzilla a
>few days ago http://issues.apache.org/bugzilla/show_bug.cgi?id=32223
>you can see how my additions to CForm uses convertor.getId() to
>construct meaningful ValidationErrors (the GlobalConvertor is the glue
>between the conversion block and CForm).
>
>>>From o.a.c.forms.datatype.convertor.GlobalConvertor
>
>public class GlobalConvertor implements Convertor {
> ...
> public ConversionResult convertFromString(String value, Locale locale,
>Convertor.FormatCache dummy) {
> try {
> return new ConversionResult(convertor.convertFromString(value, locale));
> } catch (Exception e) {
> return new ConversionResult(new ValidationError("conversion-failed." + convertor.getId()));
> }
> }
> ...
>}
>
>The reason I put in setId as well was that rather than having all
>Convertors implement Configurable and get their id that way, they can be
>fed the id by the ConvertorManager at instantiation.
>
>
Ok.
><snip/>
>
>
>>Thinking of it I would prefer:
>>
>>public Convertor getConvertor(Class c);
>>public Convertor getConvertor(Class c, Locale l);
>>public Convertor getConvertor(Class c, Locale l, String type);
>>
>>In this case we would remove Locale form the converToString and
>>convertFromString methods in the Convertor interface. That would make
>>the converters less similar to CForms converters that might be bad. But
>>it would alow more control over fallback handling in the
>>ConvertorManager. It would be easier to use also I think.
>>
>>
>
>Agree, locale in getConvertor() rather than in convertToString seems
>more reasonable.
>
>
>
>>Now, it wouldn't be that hard to reimplement the CForms convertors in
>>terms of these simpler convertors. Or to refactor CForms using this kind
>>of convertors, the convertors are not used in that many places in the
>>code. As long as the form definition files doesn't change I would
>>believe that rather few would be affected.
>>
>>
>
>In the conversion block mentioned above I included patches for CForm
>that enables form definitions to use convertors in the conversion block
>instead. These new convertors can be used alongside the old convertors
>from CForm. In the samples provided I have for example:
>
><fd:field id="date">
> <fd:datatype base="date">
> <fd:convertor type="global" refid="java.util.Date#short"/>
> </fd:datatype>
></fd:field>
>
>The "global" convertor is a normal CForm convertor but it calls the
>ConvertorManager for a convertor with id = refid when it is
>instantiated.
>
>
Had not seen that, I just assumed that your Bugzilla entry was identical
to the el.zip on your web site. That was obviously not true.
<snip/>
>I agree that locale fallback is necessary. However shouldn't the
>fallback mechanism be implemented in the Convertors themselves rather
>than in the ConvertorManager that doles out the convertors. Some
>Convertors will do fallback, others would throw exceptions and those
>that are locale insensitive would ignore the issue altogether.
>
>
Yes, I think we keep it as is, I have no important use cases that
requires the convertor manager to handle all fallback.
I need to review your code a little bit more, then I'll commit the
conversion block to the trunk (if no one protest), so that people can
start to work on it. The code for using the convertor block in CForms
has to wait a little bit longer as it is to early to make the CForms
block dependent on the conversion block.
The next steps, IMO, would be to put copies of all the CForms convertors
modified for the new interface, in the conversion block. And of course
to iron out wrinkles in the interfaces. Then when everybody is happy
about the state of the convertor block, we can refactor CForms so that
it uses the convertors from the converrtor block instead, probably with
some wrapping code so that we don't need to change any interfaces in
CForms. We can also introduce it in e.g. JXTemplateGenerator.
WDYT?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Sun, 2004-11-14 at 22:57 +0100, Daniel Fagerstrom wrote:
> Jonas Ekstedt wrote:
> > On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
> >>CForms Convertor Integration
> >>----------------------------
> <snip/>
> > How about an interface like this:
> >
> > public interface Convertor {
> >
> > public String getId();
> > public void setId(String id);
> > public Class getTypeClass();
> > public String convertToString(Object value, Locale locale)
> > throws Exception;
> > public Object convertFromString(String value, Locale locale)
> > throws Exception;
> >
> > }
> >
> > Each convertor has an id (useful for error reporting when conversion
> > fails) and a typeClass (ie the class type it converts to/from). Those
> > convertors that need extra configuration would implement Configurable.
>
> Looks good to me. Some small comments: Do we need an Exception for
> convertToString, can that go wrong? Shouldn't we use a more specialized
> Exception, conversion failure should gennerally be checked I guess.
I just threw that Exception in there for symmetry ;) it probably isn't
all that useful.
> Is
> setId necessary, or are you preparing for dependecy injection?
I think there are cases when supplying a convertor with an id can be
useful, especially when constructing error messages if conversions
failed. If you look at the conversion block that I posted to bugzilla a
few days ago http://issues.apache.org/bugzilla/show_bug.cgi?id=32223
you can see how my additions to CForm uses convertor.getId() to
construct meaningful ValidationErrors (the GlobalConvertor is the glue
between the conversion block and CForm).
>>From o.a.c.forms.datatype.convertor.GlobalConvertor
public class GlobalConvertor implements Convertor {
...
public ConversionResult convertFromString(String value, Locale locale,
Convertor.FormatCache dummy) {
try {
return new ConversionResult(convertor.convertFromString(value, locale));
} catch (Exception e) {
return new ConversionResult(new ValidationError("conversion-failed." + convertor.getId()));
}
}
...
}
The reason I put in setId as well was that rather than having all
Convertors implement Configurable and get their id that way, they can be
fed the id by the ConvertorManager at instantiation.
<snip/>
> Thinking of it I would prefer:
>
> public Convertor getConvertor(Class c);
> public Convertor getConvertor(Class c, Locale l);
> public Convertor getConvertor(Class c, Locale l, String type);
>
> In this case we would remove Locale form the converToString and
> convertFromString methods in the Convertor interface. That would make
> the converters less similar to CForms converters that might be bad. But
> it would alow more control over fallback handling in the
> ConvertorManager. It would be easier to use also I think.
Agree, locale in getConvertor() rather than in convertToString seems
more reasonable.
> Now, it wouldn't be that hard to reimplement the CForms convertors in
> terms of these simpler convertors. Or to refactor CForms using this kind
> of convertors, the convertors are not used in that many places in the
> code. As long as the form definition files doesn't change I would
> believe that rather few would be affected.
In the conversion block mentioned above I included patches for CForm
that enables form definitions to use convertors in the conversion block
instead. These new convertors can be used alongside the old convertors
from CForm. In the samples provided I have for example:
<fd:field id="date">
<fd:datatype base="date">
<fd:convertor type="global" refid="java.util.Date#short"/>
</fd:datatype>
</fd:field>
The "global" convertor is a normal CForm convertor but it calls the
ConvertorManager for a convertor with id = refid when it is
instantiated.
> Hopefully some of the more
> active CForms developers/users can comement on that.
>
> Anyway for the moment I think we should strive for simplicity and solve
> CForms compability issues later.
>
> > One problem with this type of configuration would be that it is hard to
> > implement a fallback mechanisms (eg if we don't have a
> > "java.util.Date#full" converter use "java.util.Date"). However I don't
> > know how useful fallback would be anyway (see below).
>
> I rather get a date in default locale and form than an exception if I
> use an webapp that not is localized for swedish use ;)
I agree that locale fallback is necessary. However shouldn't the
fallback mechanism be implemented in the Convertors themselves rather
than in the ConvertorManager that doles out the convertors. Some
Convertors will do fallback, others would throw exceptions and those
that are locale insensitive would ignore the issue altogether.
>
> >>What lacks in CForms Convertor from our POV, is a way to use
> >>presentation classes. Maybe also would like to have more general
> >>convertion between objects in general. I have no use cases for that and
> >>I would prefer keeping it as simple as possible.
> >
> > One possible use case for other types of conversion would be Iterator
> > conversion. This could be useful in forEach template tags. Eg:
> >
> > <forEach var="widget" items="$repeaterWidget">
> > ...
> > </forEach>
> >
> > Then you could use forEach for any object type that has an Object <->
> > Iterator convertor.
>
> Hmm... seem like overkill to use a locale and type aware conversion
> mechanism for that.
Yeah, reading that bit again, it does seem overly creative.
>
> >>Presentation Classes
> >>--------------------
> >>
> >>We need to find a good syntax for presentation classes. I'm not
> >>completely convinced about the '#' selector, as it normally is connected
> >>to positions, but I don't have any better suggestions. The
> >>${date?class=short} is unecesarilly verbose as class is the only
> >>attribute that we use. Using specialized tags might also be an
> >>alternative. But that is rather clumsy for xml attributes, and it would
> >>be nicer to have a mechanism that is not connected to a certain template
> >>language.
> >
> >
> > I think the choice of separator character is rather limited as it cannot
> > be either a legal variable name character nor a legal operator
> > character. Someone might want to do ${1+1#decimal}.
>
> "#" will be fine, I'm starting to get used to it and have not seen any
> better alternatives. I also believe that it will mainly be a concern for
> the user of the convertor, the template language e.g.
>
> >>How does type, locale and class interact? I would propose to have the
> >>priority order type > locale > class. Meaning that if type, locale and
> >>class are given the convertion component will first look for convertions
> >>having the right type, if none is given a default convertor (.toString)
> >>is used. If there are convertors of the right type but not the right
> >>locale, the default convertor for the type is used. If there are
> >>convertors of the right type and locale, but not with the right class,
> >>the default convertor for the type and locale is used.
> >
> >
> > Wouldn't it be easier to just throw an exception if the correct type of
> > convertor couldn't be found. The fallback convertor probably wouldn't be
> > what the page author had in mind anyway. Regarding locale fallback,
> > shouldn't this be up to the convertors themselves as only they know if
> > they are locale sensitive. In the example above the DefaultDateConvertor
> > can handle any locale whereas the CustomDateConvertor should throw an
> > exception if there is no pattern for the locale or alternatively use a
> > default pattern.
>
> Locale fallback is IMHO a necesity. For type I don't know, from the CSS
> class analogy we should have it, but that is just an analogy and can be
> missleading. Use cases are needed to decide. Leszek and Ralph you had
> lots of opinions earlier in this thread, what do you say?
>
> Depends also on how we distribute the decisions between the convertor
> manager and the convertors. If we keep it close to CForms convertors,
> type fallback probably becomes to complicated to be worthwhile.
>
> Anyway, it is up to the implementor to decide how much effort it is worth.
>
> >>Jonas, I still think that Bugzilla is a good place for your patches ;)
> >>Please add the Apache license to all files also. And than you for your work.
> >
> > I'll do so. I hope I won't add to much noise to the bug database.
>
> Considering the quality of your work this far, the risk for noise seems
> negligible :)
Thanks
> /Daniel
Cheers // Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@apache.org>.
Daniel Fagerstrom wrote:
>> Wouldn't it be easier to just throw an exception if the correct type of
>> convertor couldn't be found. The fallback convertor probably wouldn't be
>> what the page author had in mind anyway. Regarding locale fallback,
>> shouldn't this be up to the convertors themselves as only they know if
>> they are locale sensitive. In the example above the DefaultDateConvertor
>> can handle any locale whereas the CustomDateConvertor should throw an
>> exception if there is no pattern for the locale or alternatively use a
>> default pattern.
>
>
> Locale fallback is IMHO a necesity. For type I don't know, from the CSS
> class analogy we should have it, but that is just an analogy and can be
> missleading. Use cases are needed to decide. Leszek and Ralph you had
> lots of opinions earlier in this thread, what do you say?
I am not familiar with CForms' convertors implementation details. So
just abstract thoughts:
1. Locale fallback is a must - with the behaviour similar to i18n - are
we able to reuse that mechanism?
2. I do not really see a usecase for type fallback. There could be two
various problems that could cause fallback:
* an exception in best matched convertor - would default convertor be
any better?
* no such type: I see it rather as configuration's problem.
${date#shrot} - is that something that counts for a default convertor?
If type fallback is to be implemented I think it has to be supported by
some kind of leniency setting (you may want you view to throw exceptions
in case of spelling errors and not perform fallback).
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
> On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>>CForms Convertor Integration
>>----------------------------
<snip/>
> How about an interface like this:
>
> public interface Convertor {
>
> public String getId();
> public void setId(String id);
> public Class getTypeClass();
> public String convertToString(Object value, Locale locale)
> throws Exception;
> public Object convertFromString(String value, Locale locale)
> throws Exception;
>
> }
>
> Each convertor has an id (useful for error reporting when conversion
> fails) and a typeClass (ie the class type it converts to/from). Those
> convertors that need extra configuration would implement Configurable.
Looks good to me. Some small comments: Do we need an Exception for
convertToString, can that go wrong? Shouldn't we use a more specialized
Exception, conversion failure should gennerally be checked I guess. Is
setId necessary, or are you preparing for dependecy injection?
> The convertors would be created by a ConvertorManager configured by
> something like:
>
> <root>
> <convertor id="java.util.Date"
> src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
>
> <convertor id="java.util.Date#short"
> src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
> <style>short</style>
> </convertor>
>
> <convertor id="java.util.Date#full"
> src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
> <style>full</style>
> </convertor>
>
> <convertor id="java.util.Date#myformat"
> src="o.a.c.conversion.convertor.CustomDateConvertor"/>
> <pattern lang="en">MM/dd/yyyy</pattern>
> <pattern lang="se">yyyy-MM-dd</pattern>
> </convertor>
>
> </root>
Seem reasonable and fairly close to how the convertors from CForms are
configured, which is good from a migration POV.
I18N files are often organized per locale: msg.xml, msg_en.xml,
msg_de.xml etc. Maybe it is easier to organize localization that way. It
complicates the coupling to CForms converters though.
I have limited experience of developing multi lingual applications. I'd
like some input from people with more I18N and L10N experience about how
configuration files should be organized to be practical.
> The convertors are accessed from a ConvertorManager:
> public Convertor getConvertor(String id);
>
> The id's of each convertor would take the form of className#type so that
> whoever uses the convertors can do something like:
>
> String className = obj.getClass().getName();
> convertor = convManager.getConvertor(className + "#" + type);
> String str = convertor.convertToString(obj, locale);
Thinking of it I would prefer:
public Convertor getConvertor(Class c);
public Convertor getConvertor(Class c, Locale l);
public Convertor getConvertor(Class c, Locale l, String type);
In this case we would remove Locale form the converToString and
convertFromString methods in the Convertor interface. That would make
the converters less similar to CForms converters that might be bad. But
it would alow more control over fallback handling in the
ConvertorManager. It would be easier to use also I think.
Now, it wouldn't be that hard to reimplement the CForms convertors in
terms of these simpler convertors. Or to refactor CForms using this kind
of convertors, the convertors are not used in that many places in the
code. As long as the form definition files doesn't change I would
believe that rather few would be affected. Hopefully some of the more
active CForms developers/users can comement on that.
Anyway for the moment I think we should strive for simplicity and solve
CForms compability issues later.
> One problem with this type of configuration would be that it is hard to
> implement a fallback mechanisms (eg if we don't have a
> "java.util.Date#full" converter use "java.util.Date"). However I don't
> know how useful fallback would be anyway (see below).
I rather get a date in default locale and form than an exception if I
use an webapp that not is localized for swedish use ;)
>>What lacks in CForms Convertor from our POV, is a way to use
>>presentation classes. Maybe also would like to have more general
>>convertion between objects in general. I have no use cases for that and
>>I would prefer keeping it as simple as possible.
>
> One possible use case for other types of conversion would be Iterator
> conversion. This could be useful in forEach template tags. Eg:
>
> <forEach var="widget" items="$repeaterWidget">
> ...
> </forEach>
>
> Then you could use forEach for any object type that has an Object <->
> Iterator convertor.
Hmm... seem like overkill to use a locale and type aware conversion
mechanism for that.
>>Presentation Classes
>>--------------------
>>
>>We need to find a good syntax for presentation classes. I'm not
>>completely convinced about the '#' selector, as it normally is connected
>>to positions, but I don't have any better suggestions. The
>>${date?class=short} is unecesarilly verbose as class is the only
>>attribute that we use. Using specialized tags might also be an
>>alternative. But that is rather clumsy for xml attributes, and it would
>>be nicer to have a mechanism that is not connected to a certain template
>>language.
>
>
> I think the choice of separator character is rather limited as it cannot
> be either a legal variable name character nor a legal operator
> character. Someone might want to do ${1+1#decimal}.
"#" will be fine, I'm starting to get used to it and have not seen any
better alternatives. I also believe that it will mainly be a concern for
the user of the convertor, the template language e.g.
>>How does type, locale and class interact? I would propose to have the
>>priority order type > locale > class. Meaning that if type, locale and
>>class are given the convertion component will first look for convertions
>>having the right type, if none is given a default convertor (.toString)
>>is used. If there are convertors of the right type but not the right
>>locale, the default convertor for the type is used. If there are
>>convertors of the right type and locale, but not with the right class,
>>the default convertor for the type and locale is used.
>
>
> Wouldn't it be easier to just throw an exception if the correct type of
> convertor couldn't be found. The fallback convertor probably wouldn't be
> what the page author had in mind anyway. Regarding locale fallback,
> shouldn't this be up to the convertors themselves as only they know if
> they are locale sensitive. In the example above the DefaultDateConvertor
> can handle any locale whereas the CustomDateConvertor should throw an
> exception if there is no pattern for the locale or alternatively use a
> default pattern.
Locale fallback is IMHO a necesity. For type I don't know, from the CSS
class analogy we should have it, but that is just an analogy and can be
missleading. Use cases are needed to decide. Leszek and Ralph you had
lots of opinions earlier in this thread, what do you say?
Depends also on how we distribute the decisions between the convertor
manager and the convertors. If we keep it close to CForms convertors,
type fallback probably becomes to complicated to be worthwhile.
Anyway, it is up to the implementor to decide how much effort it is worth.
>>Jonas, I still think that Bugzilla is a good place for your patches ;)
>>Please add the Apache license to all files also. And than you for your work.
>
> I'll do so. I hope I won't add to much noise to the bug database.
Considering the quality of your work this far, the risk for noise seems
negligible :)
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-16 at 08:57 +0100, Bruno Dumon wrote:
> On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote:
> > On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
> <snip/>
> >
> > How about an interface like this:
> >
> > public interface Convertor {
> >
> > public String getId();
> > public void setId(String id);
> > public Class getTypeClass();
> > public String convertToString(Object value, Locale locale)
> > throws Exception;
> > public Object convertFromString(String value, Locale locale)
> > throws Exception;
> >
> > }
> >
> > Each convertor has an id (useful for error reporting when conversion
> > fails) and a typeClass (ie the class type it converts to/from). Those
> > convertors that need extra configuration would implement Configurable.
>
> So if convertFromString fails, you'd throw an exception? A user who
> enters something invalid is far from an exceptional condition, that's
> why currently the ConversionResult is returned which includes this
> information (exceptions are rather heavy to create).
It would be up to the component that uses the convertor to decide what
to do in case of an exception. For example we could have:
public class MyIntegerBean {
Convertor convertor;
String unparsedInteger;
Integer integer;
public MyIntegerBean() {
ConvertorManager convertorManager = ...
convertor = convertorManager.getConvertor("java.lang.Integer");
}
public void setInteger(Integer integer) {
this.integer = integer;
}
public void setInteger(String intStr, Locale locale) {
try {
integer = convertor.convertFromString(intStr, locale);
unparsedInteger = null;
} catch (Exception e) {
unparsedInteger = intStr;
}
}
public Integer getInteger() {
if (unparsedInteger != null)
throw new RuntimeException("Integer is in an unparsed state");
else
return integer;
}
public String getInteger(Locale locale) {
if (unparsedInteger != null)
return unparsedInteger;
else
return convertor.convertToString(integer, locale);
}
}
Whether the error condition should be reported via an exception or a
conversion result I really don't know. I'm a bit of a novice when it
comes to exception handling and optimization (as you might have noticed
if you look through any of my code ;) ).
Cheers Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bruno Dumon wrote:
>On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote:
>
>
>>On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>>
>>
><snip/>
>
>
>>How about an interface like this:
>>
>>public interface Convertor {
>>
>> public String getId();
>> public void setId(String id);
>> public Class getTypeClass();
>> public String convertToString(Object value, Locale locale)
>> throws Exception;
>> public Object convertFromString(String value, Locale locale)
>> throws Exception;
>>
>>}
>>
>>Each convertor has an id (useful for error reporting when conversion
>>fails) and a typeClass (ie the class type it converts to/from). Those
>>convertors that need extra configuration would implement Configurable.
>>
>>
>
>So if convertFromString fails, you'd throw an exception? A user who
>enters something invalid is far from an exceptional condition,
>
Agree abot that. The idea with the conversion block (in case you didn't
follow the long thread), is to make convertors available outside CForms,
for all kinds of input and output handling, e.g. in template languages.
The problem with ConversionResult from this POV is that it depends on
some other CForms classes (ValidationError, I18NMessage and Constants).
And the conversion block should have as few dependencies as possible.
> that's
>why currently the ConversionResult is returned which includes this
>information (exceptions are rather heavy to create).
>
>
>Originally, convertors returned null if conversion failed (and otherwise
>the converted value), but then the ConversionResult was introduced to
>allow convertors to also return an error message describing why the
>conversion failed.
>
Most of the CForms convertors have a try block around the value parsing
anyway and a catch block that creates a message in the ConversionResult
based on the type of convertor. Throwing an exception and making the
type info available seemed to be a good way to booth make it more
independent of the context where it is used and make it easy to write a
CForms-convertor wrapper for it. Even if a conversion failure isn't an
exceptional state in form handling it might be an exceptional case for
other use cases. But it is not a big deal, if you have better
suggestions we can use them instead.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote:
> On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
<snip/>
>
> How about an interface like this:
>
> public interface Convertor {
>
> public String getId();
> public void setId(String id);
> public Class getTypeClass();
> public String convertToString(Object value, Locale locale)
> throws Exception;
> public Object convertFromString(String value, Locale locale)
> throws Exception;
>
> }
>
> Each convertor has an id (useful for error reporting when conversion
> fails) and a typeClass (ie the class type it converts to/from). Those
> convertors that need extra configuration would implement Configurable.
So if convertFromString fails, you'd throw an exception? A user who
enters something invalid is far from an exceptional condition, that's
why currently the ConversionResult is returned which includes this
information (exceptions are rather heavy to create).
Originally, convertors returned null if conversion failed (and otherwise
the converted value), but then the ConversionResult was introduced to
allow convertors to also return an error message describing why the
conversion failed.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
> CForms Convertor Integration
> ----------------------------
>
> Here is the Convertor interface:
>
> public interface Convertor {
>
> /**
> * Converts string representation into the object of convertor's type.
> *
> * @param formatCache can be null if not needed
> */
> ConversionResult convertFromString(String value, Locale locale, FormatCache formatCache);
>
> String convertToString(Object value, Locale locale, FormatCache formatCache);
>
> Class getTypeClass();
>
> /**
> * Generates a bit of information about this convertor (optional).
> */
> void generateSaxFragment(ContentHandler contentHandler, Locale locale) throws SAXException;
>
> public interface FormatCache {
> public Object get();
> public void store(Object object);
> }
> }
>
> The main problem is the ConversionResult. It is a class that in turn
> uses some CForms specific stuff, (ValidationError, I18NMessage and
> Cosntants). I think the idea of having a ConversionResult is ok, but we
> need to make it independent of the rest of CForms.
>
> AFAICS we don't need the formatCache in a convertion component, each
> convertor will only be needed to be defined once. The
> generateSaxFragment is also somewhat specific for my taste, I wonder if
> that is part of the convertion concern. Furthermore it has an empty
> implementation in all the convertors within CForms, so it is hard to see
> what it is supposed to be good for.
>
> The CForms convertors is not configured the standard Avalon way. Mainly
> because the Avalon configuration doesn't handle name spaces.
How about an interface like this:
public interface Convertor {
public String getId();
public void setId(String id);
public Class getTypeClass();
public String convertToString(Object value, Locale locale)
throws Exception;
public Object convertFromString(String value, Locale locale)
throws Exception;
}
Each convertor has an id (useful for error reporting when conversion
fails) and a typeClass (ie the class type it converts to/from). Those
convertors that need extra configuration would implement Configurable.
The convertors would be created by a ConvertorManager configured by
something like:
<root>
<convertor id="java.util.Date"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<convertor id="java.util.Date#short"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<style>short</style>
</convertor>
<convertor id="java.util.Date#full"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<style>full</style>
</convertor>
<convertor id="java.util.Date#myformat"
src="o.a.c.conversion.convertor.CustomDateConvertor"/>
<pattern lang="en">MM/dd/yyyy</pattern>
<pattern lang="se">yyyy-MM-dd</pattern>
</convertor>
</root>
The convertors are accessed from a ConvertorManager:
public Convertor getConvertor(String id);
The id's of each convertor would take the form of className#type so that
whoever uses the convertors can do something like:
String className = obj.getClass().getName();
convertor = convManager.getConvertor(className + "#" + type);
String str = convertor.convertToString(obj, locale);
One problem with this type of configuration would be that it is hard to
implement a fallback mechanisms (eg if we don't have a
"java.util.Date#full" converter use "java.util.Date"). However I don't
know how useful fallback would be anyway (see below).
>
> What lacks in CForms Convertor from our POV, is a way to use
> presentation classes. Maybe also would like to have more general
> convertion between objects in general. I have no use cases for that and
> I would prefer keeping it as simple as possible.
One possible use case for other types of conversion would be Iterator
conversion. This could be useful in forEach template tags. Eg:
<forEach var="widget" items="$repeaterWidget">
...
</forEach>
Then you could use forEach for any object type that has an Object <->
Iterator convertor.
>
>
> Presentation Classes
> --------------------
>
> We need to find a good syntax for presentation classes. I'm not
> completely convinced about the '#' selector, as it normally is connected
> to positions, but I don't have any better suggestions. The
> ${date?class=short} is unecesarilly verbose as class is the only
> attribute that we use. Using specialized tags might also be an
> alternative. But that is rather clumsy for xml attributes, and it would
> be nicer to have a mechanism that is not connected to a certain template
> language.
I think the choice of separator character is rather limited as it cannot
be either a legal variable name character nor a legal operator
character. Someone might want to do ${1+1#decimal}.
>
> How does type, locale and class interact? I would propose to have the
> priority order type > locale > class. Meaning that if type, locale and
> class are given the convertion component will first look for convertions
> having the right type, if none is given a default convertor (.toString)
> is used. If there are convertors of the right type but not the right
> locale, the default convertor for the type is used. If there are
> convertors of the right type and locale, but not with the right class,
> the default convertor for the type and locale is used.
Wouldn't it be easier to just throw an exception if the correct type of
convertor couldn't be found. The fallback convertor probably wouldn't be
what the page author had in mind anyway. Regarding locale fallback,
shouldn't this be up to the convertors themselves as only they know if
they are locale sensitive. In the example above the DefaultDateConvertor
can handle any locale whereas the CustomDateConvertor should throw an
exception if there is no pattern for the locale or alternatively use a
default pattern.
<snip/>
> P.S.
>
> Jonas, I still think that Bugzilla is a good place for your patches ;)
> Please add the Apache license to all files also. And than you for your work.
I'll do so. I hope I won't add to much noise to the bug database.
Cheers // Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
<snip/>
> The date pattern is used on the client-side by the calendar widget
> which has the very good idea to use SimpleDateFormat's pattern syntax
> (actually, this is one of the reasons that made me choose this
> calendar). So (fortunately!) the user doesn't see it :-)
Ok, didn't know that. I saw "yyyy-MM-dd" in one of the samples and made
the wrong connection.
> Having the datatype output an XML fragment is the first step towards
> client-side syntactical validation.
Seem like a good idea. We should support this in the stand alone
converter as well. One possible way would be to introduce a
"PatternedConvertor" interface that is an extension of Convertor and add
a "String getPattern()" method. Then the pattern could be available from
the template expression language for making client side validation possible.
WDYT?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Joerg Heinicke wrote:
>
>> On 10.11.2004 12:15, Daniel Fagerstrom wrote:
>>
>>> AFAICS we don't need the formatCache in a convertion component, each
>>> convertor will only be needed to be defined once. The
>>> generateSaxFragment is also somewhat specific for my taste, I wonder
>>> if that is part of the convertion concern. Furthermore it has an
>>> empty implementation in all the convertors within CForms, so it is
>>> hard to see what it is supposed to be good for.
>>
>>
>> One exception:
>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/datatype/convertor/FormattingDateConvertor.java?rev=56582&view=markup
>
>
>
> Wasn't carefull enough when I browsed the code obviously.
>
>> The convertor params might be needed in the output as it is the case
>> for the DateConvertor. The pattern will be reused in the HTML output
>> for the calendar widget.
>
>
> I see, for the variant part the most popular idea in the discussion
> have been for the view to ask for what variant (presentation class)
> to use. E.g. ${$date#datetime}, meaning give me a string
> representation of the object in the $date variable using the current
> locale and the presentation class datetime. As the presentation class
> is decided in the view template, the template writer can make that
> info available for the stylesheet also, if needed.
>
> For the pattern info I don't know. Is it really a user friendly to
> present Java date formating pattern info? The difference between M, MM
> and MMM or between h and H isn't that obvious for the user I would
> believe. Maybe one could use I18N catalogues instead and get something
> a little bit more readable.
The date pattern is used on the client-side by the calendar widget which
has the very good idea to use SimpleDateFormat's pattern syntax
(actually, this is one of the reasons that made me choose this
calendar). So (fortunately!) the user doesn't see it :-)
Having the datatype output an XML fragment is the first step towards
client-side syntactical validation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke wrote:
> On 10.11.2004 12:15, Daniel Fagerstrom wrote:
>
>> AFAICS we don't need the formatCache in a convertion component, each
>> convertor will only be needed to be defined once. The
>> generateSaxFragment is also somewhat specific for my taste, I wonder
>> if that is part of the convertion concern. Furthermore it has an empty
>> implementation in all the convertors within CForms, so it is hard to
>> see what it is supposed to be good for.
>
> One exception:
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/datatype/convertor/FormattingDateConvertor.java?rev=56582&view=markup
Wasn't carefull enough when I browsed the code obviously.
> The convertor params might be needed in the output as it is the case for
> the DateConvertor. The pattern will be reused in the HTML output for the
> calendar widget.
I see, for the variant part the most popular idea in the discussion have
been for the view to ask for what variant (presentation class) to use.
E.g. ${$date#datetime}, meaning give me a string representation of the
object in the $date variable using the current locale and the
presentation class datetime. As the presentation class is decided in the
view template, the template writer can make that info available for the
stylesheet also, if needed.
For the pattern info I don't know. Is it really a user friendly to
present Java date formating pattern info? The difference between M, MM
and MMM or between h and H isn't that obvious for the user I would
believe. Maybe one could use I18N catalogues instead and get something a
little bit more readable.
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.11.2004 12:15, Daniel Fagerstrom wrote:
> AFAICS we don't need the formatCache in a convertion component, each
> convertor will only be needed to be defined once. The
> generateSaxFragment is also somewhat specific for my taste, I wonder if
> that is part of the convertion concern. Furthermore it has an empty
> implementation in all the convertors within CForms, so it is hard to see
> what it is supposed to be good for.
One exception:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/datatype/convertor/FormattingDateConvertor.java?rev=56582&view=markup
The convertor params might be needed in the output as it is the case for
the DateConvertor. The pattern will be reused in the HTML output for the
calendar widget.
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bruno Dumon wrote:
>On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
><snip/>
>
>
>>CForms Convertor Integration
>>----------------------------
>>
>>Here is the Convertor interface:
>>
>>public interface Convertor {
>>
>> /**
>> * Converts string representation into the object of convertor's type.
>> *
>> * @param formatCache can be null if not needed
>> */
>> ConversionResult convertFromString(String value, Locale locale, FormatCache formatCache);
>>
>> String convertToString(Object value, Locale locale, FormatCache formatCache);
>>
>> Class getTypeClass();
>>
>> /**
>> * Generates a bit of information about this convertor (optional).
>> */
>> void generateSaxFragment(ContentHandler contentHandler, Locale locale) throws SAXException;
>>
>> public interface FormatCache {
>> public Object get();
>> public void store(Object object);
>> }
>>}
>>
>>The main problem is the ConversionResult. It is a class that in turn
>>uses some CForms specific stuff, (ValidationError, I18NMessage and
>>Cosntants). I think the idea of having a ConversionResult is ok, but we
>>need to make it independent of the rest of CForms.
>>
>>AFAICS we don't need the formatCache in a convertion component, each
>>convertor will only be needed to be defined once
>>
>>
>
>The purpose of the formatCache is if a lot of values need to be
>converted using the same convertor, which is (or can be) the case in
>selection lists. Java's DateFormat and NumberFormat classes are not
>thread-safe,
>
Ok. didn't know that, disturbing :/
> so they need to be recreated for each conversion, and this
>can be quite heavy (eg the number or date formatting pattern must be
>reparsed each time). The format cache allows to store the prepared
>Date/NumberFormat instance, but is completely optional.
>
>
Yes, now it makes perfect sense. Would it be possible to let the
convertor manager handle some thread local Date/NumberFormat cache, so
that the user of the convertor doesn't have to manage that?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
<snip/>
> CForms Convertor Integration
> ----------------------------
>
> Here is the Convertor interface:
>
> public interface Convertor {
>
> /**
> * Converts string representation into the object of convertor's type.
> *
> * @param formatCache can be null if not needed
> */
> ConversionResult convertFromString(String value, Locale locale, FormatCache formatCache);
>
> String convertToString(Object value, Locale locale, FormatCache formatCache);
>
> Class getTypeClass();
>
> /**
> * Generates a bit of information about this convertor (optional).
> */
> void generateSaxFragment(ContentHandler contentHandler, Locale locale) throws SAXException;
>
> public interface FormatCache {
> public Object get();
> public void store(Object object);
> }
> }
>
> The main problem is the ConversionResult. It is a class that in turn
> uses some CForms specific stuff, (ValidationError, I18NMessage and
> Cosntants). I think the idea of having a ConversionResult is ok, but we
> need to make it independent of the rest of CForms.
>
> AFAICS we don't need the formatCache in a convertion component, each
> convertor will only be needed to be defined once
The purpose of the formatCache is if a lot of values need to be
converted using the same convertor, which is (or can be) the case in
selection lists. Java's DateFormat and NumberFormat classes are not
thread-safe, so they need to be recreated for each conversion, and this
can be quite heavy (eg the number or date formatting pattern must be
reparsed each time). The format cache allows to store the prepared
Date/NumberFormat instance, but is completely optional.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
>
>
>>Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/> would
>>use default renderer. Something like ${bean.startDate?class=emph} <jx:out
>>value="${bean.startDate}" styling="emph"/> would point that other convertor is
>>needed.
>>
>>
>
>I've implemented something similar to this and would be very happy to
>donate it.
>http://www.mail-archive.com/dev@cocoon.apache.org/msg23989.html
>
Cool stuff again :)
>It's basically a converter that sits on top of common-el's expression
>evaluator.
>
>You can have a template that looks like this for example
>
><p>Default conversion of date: ${date}</p>
><p>Short conversion of date: ${date#short}</p>
>
>The expression evaluator evaluates the ${date} to a Date. It then looks
>up its configuration for a Date -> String converter. Different
>converters between the same class types are differentiated by what comes
>after #.
>
>
I guess we all, or at least the participants in this thread, agree about
that we want a convertion component in Cocoon. Now the question is how
we continue.
First the convertor component must, IMO, be integrated with the
convertion stuff in CForms. Cocoon is complicated enough we don't need
two different convertor packages that does the same thing in two
slightly different ways. Especially as I, (as I have written about
earlier in this thread), would like to refactor CForms, so that it can
use the convertor component for input/output handling, instead of having
convertion being part of the data type.
So what I'd like to do is to create a convertor block and move the
convertor stuff from CForms to that block. Unfortionally the CForms
Convertor has some small dependencies on other CForms stuff. Lets look
at the details (if you are not interested in this, I discuss other
details later in the mail).
CForms Convertor Integration
----------------------------
Here is the Convertor interface:
public interface Convertor {
/**
* Converts string representation into the object of convertor's type.
*
* @param formatCache can be null if not needed
*/
ConversionResult convertFromString(String value, Locale locale, FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache formatCache);
Class getTypeClass();
/**
* Generates a bit of information about this convertor (optional).
*/
void generateSaxFragment(ContentHandler contentHandler, Locale locale) throws SAXException;
public interface FormatCache {
public Object get();
public void store(Object object);
}
}
The main problem is the ConversionResult. It is a class that in turn
uses some CForms specific stuff, (ValidationError, I18NMessage and
Cosntants). I think the idea of having a ConversionResult is ok, but we
need to make it independent of the rest of CForms.
AFAICS we don't need the formatCache in a convertion component, each
convertor will only be needed to be defined once. The
generateSaxFragment is also somewhat specific for my taste, I wonder if
that is part of the convertion concern. Furthermore it has an empty
implementation in all the convertors within CForms, so it is hard to see
what it is supposed to be good for.
The CForms convertors is not configured the standard Avalon way. Mainly
because the Avalon configuration doesn't handle name spaces.
What lacks in CForms Convertor from our POV, is a way to use
presentation classes. Maybe also would like to have more general
convertion between objects in general. I have no use cases for that and
I would prefer keeping it as simple as possible.
Presentation Classes
--------------------
We need to find a good syntax for presentation classes. I'm not
completely convinced about the '#' selector, as it normally is connected
to positions, but I don't have any better suggestions. The
${date?class=short} is unecesarilly verbose as class is the only
attribute that we use. Using specialized tags might also be an
alternative. But that is rather clumsy for xml attributes, and it would
be nicer to have a mechanism that is not connected to a certain template
language.
How does type, locale and class interact? I would propose to have the
priority order type > locale > class. Meaning that if type, locale and
class are given the convertion component will first look for convertions
having the right type, if none is given a default convertor (.toString)
is used. If there are convertors of the right type but not the right
locale, the default convertor for the type is used. If there are
convertors of the right type and locale, but not with the right class,
the default convertor for the type and locale is used.
Configuration files
-------------------
What syntax do we want? Are we using one file for all locales or
different ones? I think it would be rather usefull to have a mechanism
for extending an existing configuration file. Then we can provide some
default configuration files for differenent locales in the Cocoon
distro, that users can extend with their more specialized rules.
JXTG etc.
---------
Where is the convertion component useful, JXTG and CForms are obvious
places, IMO, other places?
WDYT?
/Daniel
P.S.
Jonas, I still think that Bugzilla is a good place for your patches ;)
Please add the Apache license to all files also. And than you for your work.
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
> Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/> would
> use default renderer. Something like ${bean.startDate?class=emph} <jx:out
> value="${bean.startDate}" styling="emph"/> would point that other convertor is
> needed.
I've implemented something similar to this and would be very happy to
donate it.
http://www.mail-archive.com/dev@cocoon.apache.org/msg23989.html
It's basically a converter that sits on top of common-el's expression
evaluator.
You can have a template that looks like this for example
<p>Default conversion of date: ${date}</p>
<p>Short conversion of date: ${date#short}</p>
The expression evaluator evaluates the ${date} to a Date. It then looks
up its configuration for a Date -> String converter. Different
converters between the same class types are differentiated by what comes
after #.
// Jonas
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Joerg Heinicke wrote:
> On 08.11.2004 14:10, Leszek Gawron wrote:
>
>> Imagine you have a bunch of java.util.Calendar properties all around
>> your JavaBeans. Now in most of the views you want to render them
>> according to a specific pattern.
>>
>> Now there are some special cases when you want those dates to get
>> additional styling as long as the date value meets specific criteria
>> so there are two things that decide if the date should be additionaly
>> emphasized:
>> - view template (some views may render the same property in plain
>> format, some may want if emphasized)
>
>
> That's pure presentation, no data involved. So put it into the view.
>
>> - date value (only the values that meet some criteria are being pretty
>> printed)
>
>
> That's dependent on data, so put a boolean property into the model
> (following Terrence Parr). In the view you can ask "if (meetsCriteria) {
> do emphasize }". A change on the criteria will result in changes to all
> views referencing the data.
got it. You're right.
>
> Of course I see you add additional stuff to the model though it looks
> like presentation logic. But you still do not depend on the
> presentation. If a template asks for this property or not is not important.
>
>> I know that this may bring inconsistency among views but as long as
>> only developer knows if the property should be styled or not there is
>> no other way.
>
>
> Don't know if you mixed something in this sentence, but this is exactly
> a reason for the above: if only developers know if property should be
> styled or not let them put a boolean property into the model.
>
>> I like Daniels comparison to a CSS class attribute.
>>
>> Something like ${bean.startDate} or <jx:out
>> value="${bean.startDate}"/> would use default renderer. Something like
>> ${bean.startDate?class=emph} <jx:out value="${bean.startDate}"
>> styling="emph"/> would point that other convertor is needed.
>>
>> If you need your view to be reusable you can do it and choose
>> convertors. The only thing is that your convertor should generate some
>> markup that will be transformed later and not HTML/WML or anything
>> specific.
>
>
> I like it too. Nothing of Parr's arguments speak against it. You only
> must not depend on the data!
Super. The thing I was most scared of was that a simplistic StringTemplate
would be main's cocoon WayToGo(tm).
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.11.2004 14:10, Leszek Gawron wrote:
> Imagine you have a bunch of java.util.Calendar properties all around
> your JavaBeans. Now in most of the views you want to render them
> according to a specific pattern.
>
> Now there are some special cases when you want those dates to get
> additional styling as long as the date value meets specific criteria so
> there are two things that decide if the date should be additionaly
> emphasized:
> - view template (some views may render the same property in plain
> format, some may want if emphasized)
That's pure presentation, no data involved. So put it into the view.
> - date value (only the values that meet some criteria are being pretty
> printed)
That's dependent on data, so put a boolean property into the model
(following Terrence Parr). In the view you can ask "if (meetsCriteria) {
do emphasize }". A change on the criteria will result in changes to all
views referencing the data.
Of course I see you add additional stuff to the model though it looks
like presentation logic. But you still do not depend on the
presentation. If a template asks for this property or not is not important.
> I know that this may bring inconsistency among views but as long as only
> developer knows if the property should be styled or not there is no
> other way.
Don't know if you mixed something in this sentence, but this is exactly
a reason for the above: if only developers know if property should be
styled or not let them put a boolean property into the model.
> I like Daniels comparison to a CSS class attribute.
>
> Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/>
> would use default renderer. Something like ${bean.startDate?class=emph}
> <jx:out value="${bean.startDate}" styling="emph"/> would point that
> other convertor is needed.
>
> If you need your view to be reusable you can do it and choose
> convertors. The only thing is that your convertor should generate some
> markup that will be transformed later and not HTML/WML or anything
> specific.
I like it too. Nothing of Parr's arguments speak against it. You only
must not depend on the data!
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Joerg Heinicke wrote:
> But why introducing dependencies into the view and not externally? How
> do you want to ensure consistent view over all templates or even over
> different applications in a software product line?
Imagine you have a bunch of java.util.Calendar properties all around your
JavaBeans. Now in most of the views you want to render them according to a
specific pattern.
Now there are some special cases when you want those dates to get additional
styling as long as the date value meets specific criteria so there are two
things that decide if the date should be additionaly emphasized:
- view template (some views may render the same property in plain format, some
may want if emphasized)
- date value (only the values that meet some criteria are being pretty printed)
I know that this may bring inconsistency among views but as long as only
developer knows if the property should be styled or not there is no other way.
I like Daniels comparison to a CSS class attribute.
Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/> would
use default renderer. Something like ${bean.startDate?class=emph} <jx:out
value="${bean.startDate}" styling="emph"/> would point that other convertor is
needed.
If you need your view to be reusable you can do it and choose convertors. The
only thing is that your convertor should generate some markup that will be
transformed later and not HTML/WML or anything specific.
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.11.2004 17:21, Leszek Gawron wrote:
>>> Still this is very inconvenient if the model is built for you i.e.
>>> object graph built by hibernate. I would have to make controller
>>> dependant on view view wants to show. Right now I just pass one
>>> entity to view and do not care if view asks for entity fields, entity
>>> parent fields, child fields, anything. If I have hibernate properly
>>> set up the data will be retrieved only when needed.
>>
>> But the view is not reusable.
>
> Now I get it why some cocooners have such a different opinion. I think
> there are two worlds that cocoon covers:
> - xml publishing, dynamic sites but with not that much business logic.
> Here the most work is put into data aggregation and rendering. I think
> your opinion represents this world.
> - web applications, totally dynamic, a lot of business logic. Most work
> is put into model and business logic. The controller is also
> significantly more complex. View is the least sophisticated here. This
> is my world :)
>
> I am developing web applications. That is why the main concern for me is
> the MODEL reusability. I do not care about the view reusability as
> almost everything is modelled in html (For styling I use single
> site2html.xsl which applies common styles, toolbar and menu). For apps I
> seldom use aggregation and 99% views are JX generated.
>
> I've done a few publishing projects. I agreee with you but only on the
> field of publishing projects where the rendering pipelines are huge and
> usually you produce data in various formats (HTML, PDF, printable HTML).
Ah, no, IMO these are not two worlds, but two parts of one world. Though
I have worked mostly on the presentation layer almost all our projects
were also web applications. And I don't see why I should abstain from
reusing my presentation layer while the model is reused.
>>> I have project that model have 5-6 depts in parent-child relationship
>>> like:
>>> contractor -> surveydefinition -> questioncategory ->
>>> questiondefinition -> alertcategory -> alertdefinition.
>>>
>>> While displaying list of entities on any level I can choose to add
>>> additional column with link to parent on any level and the only thing
>>> I have to change is the template. Model remains the same.
>>
>> If the model changes the view has also to change.
>
> What I try to emphasize: If the view changes the the model doesn't
> necessarily have to change.
>
> For web applications:
> - the model is the first to be agreed upon/designed/implemented
> - the model is the core of the application and most weight is shifted in
> that direction
> - the model is strongly typed, has a lot of constraints. Almost whole
> model consists of POJOS.
> - the model does not change much. If it does it's much bigger problem
> than just updating the views because it involves a lot of business logic
> to be changed.
>
> That is why I need my model (especially built by hibernate) to be clear
> and reusable. Not the view.
Of course. As I wrote the model must not depend on the view.
> Also I need the rendering logic to be applied in the view and not
> earlier. I need to be able to choose a convertor during view generation:
> - I might want to show property value in plain text in one place (for
> editing) and in the same view pretty printed below.
> - I do not want all Integers < 0 to be rendered red. This is based on
> the context. It is also inconvenient to put that info into the model as
> there may be a lot of orthogonal views of the same data. The model would
> have to support everyone.
But why introducing dependencies into the view and not externally? How
do you want to ensure consistent view over all templates or even over
different applications in a software product line?
>> You all seem to have only just one view in mind. What about having
>> different views for different browsers or devices? While it might be
>> easy for browsers by using XSLT and change here and there a bit, it's
>> nearly impossible for different devices. Who takes control whether to
>> show 5 widgets or 50? Using templates it's only possible by using
>> different templates. And so if the model changes the different
>> templates have also to change. And the templates are still not reusable!
>
> Probably we need either 2 templating languages or a single one covering
> both approaches.
??
>> Shall the view decide it? Even with renderers/converters this makes it
>> being not reusable. As Terrence Parr wrote: The view should be
>> reusable with a completely different model. The configuration must
>> happen externally, i.e. neither in model nor in view.
>
> This clearly makes the difference for web applications: The model should
> be reusable with a completely different view :)
We need both!
Joerg
Re: [OT]DTO Pattern (was Re: [RT] Attribute Rendering and CForms
Convertors)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ralph Goers wrote:
> Leszek Gawron wrote:
>
>> There is one big difference when using Hibernate(d) model: You do not
>> have to use DTOs so it's easier to scale the system but harder to
>> enhance particular views with some specially rendered data.
>>
>> I try to avoid DTO pattern as much as I can.
>
>
> This is completely off topic.
> My guess is that your system has a presentation tier and a database? We
> want to have all our business logic in a separate tier from
> presentation. In our case this happens to be an EJB container. Thus our
> database structure, our entity model and what is actually returned to
> the presentation tier might be very different things. I don't see how
> you can do that if you are going straight to Hibernate.
Data passed from view mostly consists of hibernate entities (and a bunch
of configuration variables but that doesn't count). Almost whole system are:
- CRUD views (create/update/delete) handled by CForms
- entity listings that allow proper navigation
The remaining 10% was of course most interesing to implement. There are
some cases (i.e. reporting, complex data manipulation) when a special
structure is being passed to the view that aggregates a lot of
information from different entities. That probably is something very
close to your DTO but as it gathers very different data I wouldn't call
them DTO (Still I might have a bad idea about what really DTO is).
When using O/R tool and having a model that defines a lot of lazy loaded
depencidencies you rarely need a custom DTO for the view.
--
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
[OT]DTO Pattern (was Re: [RT] Attribute Rendering and CForms Convertors)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Leszek Gawron wrote:
> There is one big difference when using Hibernate(d) model: You do not
> have to use DTOs so it's easier to scale the system but harder to
> enhance particular views with some specially rendered data.
>
> I try to avoid DTO pattern as much as I can.
This is completely off topic.
My guess is that your system has a presentation tier and a database? We
want to have all our business logic in a separate tier from
presentation. In our case this happens to be an EJB container. Thus our
database structure, our entity model and what is actually returned to
the presentation tier might be very different things. I don't see how
you can do that if you are going straight to Hibernate.
I'm not saying we couldn't use Hibernate. However, if we did it would be
in the business tier as a way to persist our entities. Converting to do
that would have no impact at all on our DTOs. Even if we combined the
presentation tier and business tier, I'd probably still use the pattern
just to keep the clean line between the presentation logic and business
logic.
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ralph Goers wrote:
<snip>agree to all</snip>
> Maybe this is just a different way to say the same thing. In our
> environment we designed and developed the business entities first
> independent of any view. We then determined what DTOs needed to be
> transfered to the presentation tier based upon the data the use cases
> would need, sharing DTOs where that is possible. Then the Business
> Delegates/Session Facades were implemented to return those DTOs. At the
> same time the View was implemented using mock DTOs. Finally the two
> tiers were tied together.
There is one big difference when using Hibernate(d) model: You do not
have to use DTOs so it's easier to scale the system but harder to
enhance particular views with some specially rendered data.
I try to avoid DTO pattern as much as I can.
> Looks like we all agree on this.
Yes
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 07.11.2004 22:22, Ralph Goers wrote:
>
>>> That's the way we did it until now too. But all with only one view.
>>> What's your experience when supporting your multiple views? An
>>> additional needed field in one of your forms should result in
>>> editing so many views or isn't it?
>>
>>
>> I'm not sure I understand the last question. We use a lot of
>> "preference" data (i.e. configuration) to allow a single use case to
>> use the same xslts across the board. The preferences allow the view
>> to change dramatically.
>
>
> Sample: You have an object, that can be viewed and edited. This object
> will be extended by adding a further required field when editing it
> and would be of interest when viewing it. How much effort do you need
> to update all the views that reference it? To what degree can you
> reuse your views?
> For such a change CForms is really bad. I had to update definitions,
> bindings, template so often!
That's for this kind of use case that I added the ability to set
attributes in the widget definition. We have some use cases where
generic templates are used that iterate on the children of a container
(struct, form or repeater) and layout those widgets that have a
particular attribute. That way, a single page template can be used for
different form models, or also adapt to model changes.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz said:
>
> On which level does your configuration data (LDAP) describe your page?
> Let's say
> that you have a personDTO and you add a birthdate property. Whould this
> make it
> necessary to update all configurations that describe pages using the
> personDTO?
No. Our configurations are tiered, so if the specific site does not have a
definition the default is used. In this case, the default would most
likely cause the birthdate to not be displayed since it hadn't existed
before. Then sites that want to birthdate would enable it.
Ralph
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Joerg Heinicke wrote:
>
>> So your view is more data-driven? We had this in our first Cocoon
>> project Lofex. We had an XML representing the data from the model and
>> XSLT to transform it into HTML (but no configuration how to or what to
>> display, just one XSLT per page). May I ask for more details on your
>> approach. One possible problem I see for a
>> all-and-everything-presentation layer is the decision "how much to put
>> into one page", e.g. for mobile phones. Do you just not need this or
>> how do you have it solved?
>>
>> I'm interested in it because I write my diploma thesis exactly about
>> this topic at the moment. I come to the conclusion that MVC more or
>> less can not work - and especially templates! I switched back to a
>> similar solution to the mentioned Lofex one (i.e. application-driven)
>> but with a more sophisticated model than just the data of the
>> application as it was for Lofex. It's build on the pattern
>> "Presentation Abstraction Control" I read first about in German
>> Javamagazin 09/2004.
>
>
> I doubt we would use the same XSLTs if our target was a different
> device. We would probably have a whole different set for mobile phones
> because the stylesheets would probably have very little in common.. This
> wouldn't be too big a problem for us. Our main goal is not to have a
> unique stylesheet for every site.
>
> Basically, we have a bunch of configuration data in an LDAP repository.
> That data contains the configuration information for one site. A
> generator then converts that data into an XML document that is
> aggregated together with our DTO data. The stylesheets then use the
> data from the model (the DTO) along with the configuration to figure out
> how to layout the page and what the content should be. This is a
> simplified version of what happens, but hopefully you get the idea.
On which level does your configuration data (LDAP) describe your page? Let's say
that you have a personDTO and you add a birthdate property. Whould this make it
necessary to update all configurations that describe pages using the personDTO?
--
Reinhard
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> So your view is more data-driven? We had this in our first Cocoon
> project Lofex. We had an XML representing the data from the model and
> XSLT to transform it into HTML (but no configuration how to or what to
> display, just one XSLT per page). May I ask for more details on your
> approach. One possible problem I see for a
> all-and-everything-presentation layer is the decision "how much to put
> into one page", e.g. for mobile phones. Do you just not need this or
> how do you have it solved?
>
> I'm interested in it because I write my diploma thesis exactly about
> this topic at the moment. I come to the conclusion that MVC more or
> less can not work - and especially templates! I switched back to a
> similar solution to the mentioned Lofex one (i.e. application-driven)
> but with a more sophisticated model than just the data of the
> application as it was for Lofex. It's build on the pattern
> "Presentation Abstraction Control" I read first about in German
> Javamagazin 09/2004.
I doubt we would use the same XSLTs if our target was a different
device. We would probably have a whole different set for mobile phones
because the stylesheets would probably have very little in common.. This
wouldn't be too big a problem for us. Our main goal is not to have a
unique stylesheet for every site.
Basically, we have a bunch of configuration data in an LDAP repository.
That data contains the configuration information for one site. A
generator then converts that data into an XML document that is
aggregated together with our DTO data. The stylesheets then use the
data from the model (the DTO) along with the configuration to figure out
how to layout the page and what the content should be. This is a
simplified version of what happens, but hopefully you get the idea.
Ralph
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.11.2004 16:07, Reinhard Poetz wrote:
>> I'm interested in it because I write my diploma thesis exactly about
>> this topic at the moment. I come to the conclusion that MVC more or
>> less can not work - and especially templates! I switched back to a
>> similar solution to the mentioned Lofex one (i.e. application-driven)
>> but with a more sophisticated model than just the data of the
>> application as it was for Lofex. It's build on the pattern
>> "Presentation Abstraction Control" I read first about in German
>> Javamagazin 09/2004.
>
> I (tried to) read this article. AFAIU interesting stuff but a little too
> academic IMHO.
But it's from his practical experience :-)
> Then I followed the reference to
> http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html which
> is easier to understand.
This article is not that scientifical ("Let's define darkness as new
industry standard."). And it contains some statements I definitely can
not agree with ("Gripe #2. Different views into the same object"). And
it's not about PAC, but just visual proxy.
> The main adavantage of this visual-proxy pattern (which is based upon
> the presentation abstraction control pattern) is, that the complete
> information that belongs to a certain object is encapsulated by it. If
> you need another property on your object, you simply change one object
> and every other object using it doesn't have to be changed.
Exactly. MVC with getters for data on the object break
object-orientation as you make the data or its implementation public.
Instead of asking for the data you ask for the proxy, an object that
allows you to present or edit the data. The data itself and its
implementation is encapsulated into this object.
> As you pointed out, cForms requires you to change on many places in the
> case you want to add another property to your object. Is this the price
> to pay, if you want to seperate presentation from data definition to get
> the possibility to support more then one view?
>
> Can you describe the result of your research in your thesis?
The VP article is about having just one view (see gripe #2 mentioned
above). I can not agree with it and I want to use VP in web
applications. My thesis will be about having the advantages of PAC/VP
and Cocoon.
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> On 08.11.2004 21:24, Ralph Goers wrote:
>
>>> Sample: You have an object, that can be viewed and edited. This object
>>> will be extended by adding a further required field when editing it and
>>> would be of interest when viewing it. How much effort do you need to
>>> update all the views that reference it? To what degree can you reuse
>>> your views?
>>> For such a change CForms is really bad. I had to update definitions,
>>> bindings, template so often!
>>
>>
>> I see where we are not connecting. In my case the issue is not that a
>> lot
>> of views need to be modified when an object changes. It is that a single
>> use case can have many views. In this case, we have a single xslt (or a
>> few) that uses parameters to determine what to display and how to do it.
>
>
> So your view is more data-driven? We had this in our first Cocoon
> project Lofex. We had an XML representing the data from the model and
> XSLT to transform it into HTML (but no configuration how to or what to
> display, just one XSLT per page). May I ask for more details on your
> approach. One possible problem I see for a
> all-and-everything-presentation layer is the decision "how much to put
> into one page", e.g. for mobile phones. Do you just not need this or how
> do you have it solved?
>
> I'm interested in it because I write my diploma thesis exactly about
> this topic at the moment. I come to the conclusion that MVC more or less
> can not work - and especially templates! I switched back to a similar
> solution to the mentioned Lofex one (i.e. application-driven) but with a
> more sophisticated model than just the data of the application as it was
> for Lofex. It's build on the pattern "Presentation Abstraction Control"
> I read first about in German Javamagazin 09/2004.
I (tried to) read this article. AFAIU interesting stuff but a little too
academic IMHO.
Then I followed the reference to
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html which is
easier to understand.
The main adavantage of this visual-proxy pattern (which is based upon the
presentation abstraction control pattern) is, that the complete information that
belongs to a certain object is encapsulated by it. If you need another property
on your object, you simply change one object and every other object using it
doesn't have to be changed.
As you pointed out, cForms requires you to change on many places in the case you
want to add another property to your object. Is this the price to pay, if you
want to seperate presentation from data definition to get the possibility to
support more then one view?
Can you describe the result of your research in your thesis?
--
Reinhard
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.11.2004 21:24, Ralph Goers wrote:
>>Sample: You have an object, that can be viewed and edited. This object
>>will be extended by adding a further required field when editing it and
>>would be of interest when viewing it. How much effort do you need to
>>update all the views that reference it? To what degree can you reuse
>>your views?
>>For such a change CForms is really bad. I had to update definitions,
>>bindings, template so often!
>
> I see where we are not connecting. In my case the issue is not that a lot
> of views need to be modified when an object changes. It is that a single
> use case can have many views. In this case, we have a single xslt (or a
> few) that uses parameters to determine what to display and how to do it.
So your view is more data-driven? We had this in our first Cocoon
project Lofex. We had an XML representing the data from the model and
XSLT to transform it into HTML (but no configuration how to or what to
display, just one XSLT per page). May I ask for more details on your
approach. One possible problem I see for a
all-and-everything-presentation layer is the decision "how much to put
into one page", e.g. for mobile phones. Do you just not need this or how
do you have it solved?
I'm interested in it because I write my diploma thesis exactly about
this topic at the moment. I come to the conclusion that MVC more or less
can not work - and especially templates! I switched back to a similar
solution to the mentioned Lofex one (i.e. application-driven) but with a
more sophisticated model than just the data of the application as it was
for Lofex. It's build on the pattern "Presentation Abstraction Control"
I read first about in German Javamagazin 09/2004.
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke said:
>
> Sample: You have an object, that can be viewed and edited. This object
> will be extended by adding a further required field when editing it and
> would be of interest when viewing it. How much effort do you need to
> update all the views that reference it? To what degree can you reuse
> your views?
> For such a change CForms is really bad. I had to update definitions,
> bindings, template so often!
I see where we are not connecting. In my case the issue is not that a lot
of views need to be modified when an object changes. It is that a single
use case can have many views. In this case, we have a single xslt (or a
few) that uses parameters to determine what to display and how to do it.
We aren't using CForms yet. We might after it is marked stable.
Ralph
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.11.2004 22:22, Ralph Goers wrote:
>> That's the way we did it until now too. But all with only one view.
>> What's your experience when supporting your multiple views? An
>> additional needed field in one of your forms should result in editing
>> so many views or isn't it?
>
>
> I'm not sure I understand the last question. We use a lot of
> "preference" data (i.e. configuration) to allow a single use case to use
> the same xslts across the board. The preferences allow the view to
> change dramatically.
Sample: You have an object, that can be viewed and edited. This object
will be extended by adding a further required field when editing it and
would be of interest when viewing it. How much effort do you need to
update all the views that reference it? To what degree can you reuse
your views?
For such a change CForms is really bad. I had to update definitions,
bindings, template so often!
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> That's the way we did it until now too. But all with only one view.
> What's your experience when supporting your multiple views? An
> additional needed field in one of your forms should result in editing
> so many views or isn't it?
I'm not sure I understand the last question. We use a lot of
"preference" data (i.e. configuration) to allow a single use case to use
the same xslts across the board. The preferences allow the view to
change dramatically.
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.11.2004 18:23, Ralph Goers wrote:
>> For web applications:
>> - the model is the first to be agreed upon/designed/implemented
>> - the model is the core of the application and most weight is shifted
>> in that direction
>> - the model is strongly typed, has a lot of constraints. Almost whole
>> model consists of POJOS.
>> - the model does not change much. If it does it's much bigger problem
>> than just updating the views because it involves a lot of business
>> logic to be changed.
>
> Maybe this is just a different way to say the same thing. In our
> environment we designed and developed the business entities first
> independent of any view. We then determined what DTOs needed to be
> transfered to the presentation tier based upon the data the use cases
> would need, sharing DTOs where that is possible. Then the Business
> Delegates/Session Facades were implemented to return those DTOs. At the
> same time the View was implemented using mock DTOs. Finally the two
> tiers were tied together.
That's the way we did it until now too. But all with only one view.
What's your experience when supporting your multiple views? An
additional needed field in one of your forms should result in editing so
many views or isn't it?
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Ralph Goers <Ra...@dslextreme.com>.
Leszek Gawron wrote:
> Now I get it why some cocooners have such a different opinion. I think
> there are two worlds that cocoon covers:
> - xml publishing, dynamic sites but with not that much business logic.
> Here the most work is put into data aggregation and rendering. I think
> your opinion represents this world.
> - web applications, totally dynamic, a lot of business logic. Most
> work is put into model and business logic. The controller is also
> significantly more complex. View is the least sophisticated here. This
> is my world :)
Actually, I live in yet a different world. We have a single webapp with
a lot of business logic (in an EJB tier, though). However the webapp can
take on 1600 look and feels depending on how our customers want to view
the data. They can change what columns appear, what order the columns
are in, whether or not to show a column that has no data, in addition to
the "normal" things such as changing the graphics and labels on the
page, or how the navigation is laid out. In fact, Cocoon's ability to
do this is exactly why it was chosen. In this world everything is
complex, including the presentation logic.
>
> I am developing web applications. That is why the main concern for me
> is the MODEL reusability. I do not care about the view reusability as
> almost everything is modelled in html (For styling I use single
> site2html.xsl which applies common styles, toolbar and menu). For apps
> I seldom use aggregation and 99% views are JX generated.
We use tons of aggregation. We aren't using Cocoon forms yet and only a
little JX.
>
> What I try to emphasize: If the view changes the the model doesn't
> necessarily have to change.
I couldn't agree more. In fact, we have several views of the same model.
>
> For web applications:
> - the model is the first to be agreed upon/designed/implemented
> - the model is the core of the application and most weight is shifted
> in that direction
> - the model is strongly typed, has a lot of constraints. Almost whole
> model consists of POJOS.
> - the model does not change much. If it does it's much bigger problem
> than just updating the views because it involves a lot of business
> logic to be changed.
Maybe this is just a different way to say the same thing. In our
environment we designed and developed the business entities first
independent of any view. We then determined what DTOs needed to be
transfered to the presentation tier based upon the data the use cases
would need, sharing DTOs where that is possible. Then the Business
Delegates/Session Facades were implemented to return those DTOs. At the
same time the View was implemented using mock DTOs. Finally the two
tiers were tied together.
>
> That is why I need my model (especially built by hibernate) to be
> clear and reusable. Not the view.
>
> Also I need the rendering logic to be applied in the view and not
> earlier. I need to be able to choose a convertor during view generation:
> - I might want to show property value in plain text in one place (for
> editing) and in the same view pretty printed below.
> - I do not want all Integers < 0 to be rendered red. This is based on
> the context. It is also inconvenient to put that info into the model
> as there may be a lot of orthogonal views of the same data. The model
> would have to support everyone.
I concur. Not only is it inconvenient to put that info into the model,
it is inappropriate. It as a violation of SOC.
>
>> Shall the view decide it? Even with renderers/converters this makes
>> it being not reusable. As Terrence Parr wrote: The view should be
>> reusable with a completely different model. The configuration must
>> happen externally, i.e. neither in model nor in view.
>
> This clearly makes the difference for web applications: The model
> should be reusable with a completely different view :)
Looks like we all agree on this.
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Antonio Gallardo <ag...@agssa.net>.
Leszek Gawron dijo:
> Joerg Heinicke wrote:
>> On 05.11.2004 11:19, Leszek Gawron wrote:
>>> Still this is very inconvenient if the model is built for you i.e.
>>> object graph built by hibernate. I would have to make controller
>>> dependant on view view wants to show. Right now I just pass one entity
>>> to view and do not care if view asks for entity fields, entity parent
>>> fields, child fields, anything. If I have hibernate properly set up
>>> the data will be retrieved only when needed.
>>
>>
>> But the view is not reusable.
> Now I get it why some cocooners have such a different opinion. I think
> there are two worlds that cocoon covers:
> - xml publishing, dynamic sites but with not that much business logic.
> Here the most work is put into data aggregation and rendering. I think
> your opinion represents this world.
> - web applications, totally dynamic, a lot of business logic. Most work
> is put into model and business logic. The controller is also
> significantly more complex. View is the least sophisticated here. This
> is my world :)
Yep. This is true. To me this exactly one of the most interesting parts of
Cocoon. We like to see solutions that fit in both worlds.
Often we find it ;-)
This is one of the things why Cocoon rocks!
> I am developing web applications. That is why the main concern for me is
> the MODEL reusability. I do not care about the view reusability as
> almost everything is modelled in html (For styling I use single
> site2html.xsl which applies common styles, toolbar and menu). For apps I
> seldom use aggregation and 99% views are JX generated.
I think is posible to care a lot about the MODEL reusability and at the
same time use rendering pipelines for various formats.
In my case JXTG represent cca. 40-50 % of the views.
> I've done a few publishing projects. I agreee with you but only on the
> field of publishing projects where the rendering pipelines are huge and
> usually you produce data in various formats (HTML, PDF, printable HTML).
>
>>> I have project that model have 5-6 depts in parent-child relationship
>>> like:
>>> contractor -> surveydefinition -> questioncategory ->
>>> questiondefinition -> alertcategory -> alertdefinition.
>>>
>>> While displaying list of entities on any level I can choose to add
>>> additional column with link to parent on any level and the only thing
>>> I have to change is the template. Model remains the same.
>> If the model changes the view has also to change.
> What I try to emphasize: If the view changes the the model doesn't
> necessarily have to change.
I think this is correct and currently is working in this way or not?
The SoC idea means both (model and view) are independents each other.
> For web applications:
> - the model is the first to be agreed upon/designed/implemented
> - the model is the core of the application and most weight is shifted in
> that direction
> - the model is strongly typed, has a lot of constraints. Almost whole
> model consists of POJOS.
> - the model does not change much. If it does it's much bigger problem
> than just updating the views because it involves a lot of business logic
> to be changed.
>
> That is why I need my model (especially built by hibernate) to be clear
> and reusable. Not the view.
>
> Also I need the rendering logic to be applied in the view and not
> earlier. I need to be able to choose a convertor during view generation:
> - I might want to show property value in plain text in one place (for
> editing) and in the same view pretty printed below.
> - I do not want all Integers < 0 to be rendered red. This is based on
> the context. It is also inconvenient to put that info into the model as
> there may be a lot of orthogonal views of the same data. The model would
> have to support everyone.
Yep. This is the idea. But we need to take care that there can be other
rendering views too.
>> You all seem to have
>> only just one view in mind. What about having different views for
>> different browsers or devices? While it might be easy for browsers by
>> using XSLT and change here and there a bit, it's nearly impossible for
>> different devices. Who takes control whether to show 5 widgets or 50?
>> Using templates it's only possible by using different templates. And so
>> if the model changes the different templates have also to change. And
>> the templates are still not reusable!
> Probably we need either 2 templating languages or a single one covering
> both approaches.
The later better. Or what about 1 tranformer for the views?
>> Shall the view decide it? Even with renderers/converters this makes it
>> being not reusable. As Terrence Parr wrote: The view should be reusable
>> with a completely different model. The configuration must happen
>> externally, i.e. neither in model nor in view.
> This clearly makes the difference for web applications: The model should
> be reusable with a completely different view :)
Both statements share in common what I told above:
I think is posible to care a lot about the MODEL reusability and at the
same time use rendering pipelines for various formats.
Best Regards,
Antonio Gallardo
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Joerg Heinicke wrote:
> On 05.11.2004 11:19, Leszek Gawron wrote:
>> Still this is very inconvenient if the model is built for you i.e.
>> object graph built by hibernate. I would have to make controller
>> dependant on view view wants to show. Right now I just pass one entity
>> to view and do not care if view asks for entity fields, entity parent
>> fields, child fields, anything. If I have hibernate properly set up
>> the data will be retrieved only when needed.
>
>
> But the view is not reusable.
Now I get it why some cocooners have such a different opinion. I think
there are two worlds that cocoon covers:
- xml publishing, dynamic sites but with not that much business logic.
Here the most work is put into data aggregation and rendering. I think
your opinion represents this world.
- web applications, totally dynamic, a lot of business logic. Most work
is put into model and business logic. The controller is also
significantly more complex. View is the least sophisticated here. This
is my world :)
I am developing web applications. That is why the main concern for me is
the MODEL reusability. I do not care about the view reusability as
almost everything is modelled in html (For styling I use single
site2html.xsl which applies common styles, toolbar and menu). For apps I
seldom use aggregation and 99% views are JX generated.
I've done a few publishing projects. I agreee with you but only on the
field of publishing projects where the rendering pipelines are huge and
usually you produce data in various formats (HTML, PDF, printable HTML).
>> I have project that model have 5-6 depts in parent-child relationship
>> like:
>> contractor -> surveydefinition -> questioncategory ->
>> questiondefinition -> alertcategory -> alertdefinition.
>>
>> While displaying list of entities on any level I can choose to add
>> additional column with link to parent on any level and the only thing
>> I have to change is the template. Model remains the same.
>
>
> If the model changes the view has also to change.
What I try to emphasize: If the view changes the the model doesn't
necessarily have to change.
For web applications:
- the model is the first to be agreed upon/designed/implemented
- the model is the core of the application and most weight is shifted in
that direction
- the model is strongly typed, has a lot of constraints. Almost whole
model consists of POJOS.
- the model does not change much. If it does it's much bigger problem
than just updating the views because it involves a lot of business logic
to be changed.
That is why I need my model (especially built by hibernate) to be clear
and reusable. Not the view.
Also I need the rendering logic to be applied in the view and not
earlier. I need to be able to choose a convertor during view generation:
- I might want to show property value in plain text in one place (for
editing) and in the same view pretty printed below.
- I do not want all Integers < 0 to be rendered red. This is based on
the context. It is also inconvenient to put that info into the model as
there may be a lot of orthogonal views of the same data. The model would
have to support everyone.
> You all seem to have
> only just one view in mind. What about having different views for
> different browsers or devices? While it might be easy for browsers by
> using XSLT and change here and there a bit, it's nearly impossible for
> different devices. Who takes control whether to show 5 widgets or 50?
> Using templates it's only possible by using different templates. And so
> if the model changes the different templates have also to change. And
> the templates are still not reusable!
Probably we need either 2 templating languages or a single one covering
both approaches.
> Shall the view decide it? Even with renderers/converters this makes it
> being not reusable. As Terrence Parr wrote: The view should be reusable
> with a completely different model. The configuration must happen
> externally, i.e. neither in model nor in view.
This clearly makes the difference for web applications: The model should
be reusable with a completely different view :)
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.11.2004 11:19, Leszek Gawron wrote:
>> Terence Parr sugests that test like "$bloodPressure<120" in the view
>> should be performed in the model and tested in the view like
>> "!$bloodPressureOk". He even says that:
>>
>> Even simple tests that make negative values red should be
>> computed in the model; the right level of abstraction is usually
>> something higher level such as “department x is losing
>> money.”
>
> Still this is very inconvenient if the model is built for you i.e.
> object graph built by hibernate. I would have to make controller
> dependant on view view wants to show. Right now I just pass one entity
> to view and do not care if view asks for entity fields, entity parent
> fields, child fields, anything. If I have hibernate properly set up the
> data will be retrieved only when needed.
But the view is not reusable.
> I have project that model have 5-6 depts in parent-child relationship like:
> contractor -> surveydefinition -> questioncategory -> questiondefinition
> -> alertcategory -> alertdefinition.
>
> While displaying list of entities on any level I can choose to add
> additional column with link to parent on any level and the only thing I
> have to change is the template. Model remains the same.
If the model changes the view has also to change. You all seem to have
only just one view in mind. What about having different views for
different browsers or devices? While it might be easy for browsers by
using XSLT and change here and there a bit, it's nearly impossible for
different devices. Who takes control whether to show 5 widgets or 50?
Using templates it's only possible by using different templates. And so
if the model changes the different templates have also to change. And
the templates are still not reusable!
> If I had to prepare data for view in such detailed manner as Terence
> proposes I would have to:
> - break whole entity tree
> - forget about lazy-loading
> - fetch data on each level separately
> - prepare some kind of DTOs that would apply "view needs" to data stored
> in database
> - build another object graph only for the sake of one view
> and above all:
> - change my model every time I change view template
Of course that's neither a way. The model *must* be independent of the
view. But isn't this what the renderers/converters are about?
> and still: I do not see any gain if I did that. The code is boasted,
> harder to maintain as more dependencies are introduced and much more buggy.
>
> Shouldn't SoC help making the app clearer and more flexible instead of
> making it harder?
Of course. You separate into model, view and inbetween renderers. That's
what Terrence Parr suggests.
> If I would be able to choose convertors I might decide IN VIEW ITSELF
> that that specific model value should be coloured/pretty
> printed/rendered according to some specific logic. As long as this logic
> has read-only access to model and performs steps to produce some
> rendering I do not find it SoC break.
Shall the view decide it? Even with renderers/converters this makes it
being not reusable. As Terrence Parr wrote: The view should be reusable
with a completely different model. The configuration must happen
externally, i.e. neither in model nor in view.
Joerg
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
>>
>> What that means is that a convertor should be able to do the following
>> conversions:
>> - string+locale --> object : parsing request parameters
>> - object+locale --> string : producing the value of an input
>> - object+locale+channel --> xml fragment : producing the output view
>> for a particular channel (html, wap, fo, etc).
>>
>> WDYT?
>
>
> Interesting idea! Question is how do we now that a negative number is a
> financial entity rather than a temperature, e.g. In the renderer we only
> know the type of the object to render. Of course if we use more fine
> grained data types like FinancialNumber and Temperature it would be
> feasible. But wouldn't that be to let view concerns slip into the model?
Shouldn't user be able to choose a convertor?
>
> Terence Parr sugests that test like "$bloodPressure<120" in the view
> should be performed in the model and tested in the view like
> "!$bloodPressureOk". He even says that:
>
> Even simple tests that make negative values red should be
> computed in the model; the right level of abstraction is usually
> something higher level such as “department x is losing
> money.”
Still this is very inconvenient if the model is built for you i.e. object
graph built by hibernate. I would have to make controller dependant on view
view wants to show. Right now I just pass one entity to view and do not care
if view asks for entity fields, entity parent fields, child fields, anything.
If I have hibernate properly set up the data will be retrieved only when needed.
I have project that model have 5-6 depts in parent-child relationship like:
contractor -> surveydefinition -> questioncategory -> questiondefinition ->
alertcategory -> alertdefinition.
While displaying list of entities on any level I can choose to add additional
column with link to parent on any level and the only thing I have to change is
the template. Model remains the same.
If I had to prepare data for view in such detailed manner as Terence proposes
I would have to:
- break whole entity tree
- forget about lazy-loading
- fetch data on each level separately
- prepare some kind of DTOs that would apply "view needs" to data stored in
database
- build another object graph only for the sake of one view
and above all:
- change my model every time I change view template
and still: I do not see any gain if I did that. The code is boasted, harder to
maintain as more dependencies are introduced and much more buggy.
Shouldn't SoC help making the app clearer and more flexible instead of making
it harder?
If I would be able to choose convertors I might decide IN VIEW ITSELF that
that specific model value should be coloured/pretty printed/rendered according
to some specific logic. As long as this logic has read-only access to model
and performs steps to produce some rendering I do not find it SoC break.
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> In the (often cited on this list) article: Enforcing Strict Model
>> View Separation in Template Engines, by Terence Parr
>> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, a number of
>> rules for strict separation between model and view are given. One of
>> them is that the view shouldn't make any assumptions about data types
>> of the model data. The view should only get displayable strings.
>
> I don't agree with this rule as, in order to avoid the view to know
> about the model, it requires the model to know about the view. IMO,
> the view should be given the necessary pointers to access the model
> data it needs. The granularity of these pointers is the key point that
> has to be chosen wisely.
I'm not certain that I agree with his rules either. I'm always looking
for better ways to better ways to separate content from view (and
finding god SoC in general in my apps). It is far to easy to write
"write only" code, code that felt natural when you wrote it, but is hard
to understand when you get back to it a couple of months later. I found
Terence Parr's article interesting and inspiring and trying to see if we
can apply these ideas in Cocoon webapps.
I also think that we as a community must work hard to not let to much
Java slip into the view aspects of Cocoon. It happens very easy as most
of us at cocoon-dev are Java programmers. So a first reaction is often
that; I want the full power of Java (or at least programming), in my
view, in my form handling, in my controller and everywhere. But as soon
we let do that, we makes it much harder to enforce SoC and we makes it
very hard for non-programmers to be part of our webapp development projects.
Terence Parr says about templates: "If it looks like a program, it
probably is."
> Your convertor proposal below can be a good way for the controller not
> to know too much about the view needs and for the view not to depend
> too much on the implementation details of the model.
Yes, it would at least take away some irritating rendering code from the
view or from the model. Enforcing strict model view separation in
Terence Parr's terminology is not probably not possible as long as we
use powerfull expression engines like JXPath or JEXL, I'm not, (yet at
least), certain that I would find it desirable either.
<snip/>
>> I think the renderer component idea could give a better SoC in CForms
>> as well. I have had a feeling that data type convertion is not a
>> natural part of the model (form definition) for a while. A problem is
>> that conversion configuration must be repeated each time the data
>> type is used.
>
> The repeated configuration is a problem that will be solved once we
> have the ability to define widget types and repositories [1].
Yes, that problem would disappear. Still a converter/renderer step,
IMHO, would give a nicer SoC, see my reply to Jonas for details. Also a
converter/renderer component with default configiruation files, would be
usable for rendering of non cforms data also.
A related question: will the widget types still contain label
information, or will the label info be a concern for the template instead?
<snip/>
>> So, the basic idea is to factor out the type conversion
>> functionallity from CForms and make it available for all rendering
>> and input handling needs in Cocoon.
>
> This is an interesting idea, which could be even more useful if the
> convertors were able not only to produce strings, but also XML
> snippets for output-only data. For example, we may want an email
> address to be rendered as a <a href="mailto.."> or negative numbers
> being displayed in red, or enclosed in parenthesis.
>
> What that means is that a convertor should be able to do the following
> conversions:
> - string+locale --> object : parsing request parameters
> - object+locale --> string : producing the value of an input
> - object+locale+channel --> xml fragment : producing the output view
> for a particular channel (html, wap, fo, etc).
>
> WDYT?
Interesting idea! Question is how do we now that a negative number is a
financial entity rather than a temperature, e.g. In the renderer we only
know the type of the object to render. Of course if we use more fine
grained data types like FinancialNumber and Temperature it would be
feasible. But wouldn't that be to let view concerns slip into the model?
Terence Parr sugests that test like "$bloodPressure<120" in the view
should be performed in the model and tested in the view like
"!$bloodPressureOk". He even says that:
Even simple tests that make negative values red should be
computed in the model; the right level of abstraction is usually
something higher level such as “department x is losing
money.”
I found that a little bit fundementalistic and still prefer to have it
in the view:
<jx:choose>
<jx:when test="$value<0">
<span class="loss">{$value}</span>
</jx:when>
<jx:otherwise>
<span class="winn">{$value}</span>
</jx:otherwise>
</jx:choose>
preferably put in a template so that I don't have to see it more than once.
Here we obviously let data types slip into the view. Reconnecting to the
previous discussion with Jonas about data types accesible in the view,
this would mean that boolean are needed also. In a test attribute the
template engine asks for a boolean. In a forEach an iterator is asked
for and when a value is needed this will be pased thrue the rendering
step to create a string or possibly an XML snippet. So the renderer
still simplifies things, but we don't have any "strict separation"
I would prefer to have stricter separation than that, any ideas about
how to achieve that?
/Daniel
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Sylvain Wallez wrote:
>>
>>> This is an interesting idea, which could be even more useful if the
>>> convertors were able not only to produce strings, but also XML
>>> snippets for output-only data. For example, we may want an email
>>> address to be rendered as a <a href="mailto.."> or negative numbers
>>> being displayed in red, or enclosed in parenthesis.
>>>
>>> What that means is that a convertor should be able to do the
>>> following conversions:
>>> - string+locale --> object : parsing request parameters
>>> - object+locale --> string : producing the value of an input
>>> - object+locale+channel --> xml fragment : producing the output view
>>> for a particular channel (html, wap, fo, etc).
>>
>>
>> If I would be able to choose convertors in the template (I mean on the
>> same page render model entry in plain text and pretty printed) it
>> would solve a LOT of my rendering problems. If convertors were
>> pluggable I could also choose which convertor I would like to use in
>> template itself.
>>
>> Lovely
>
> :-) More polish beer!!!
Apparently. Would you like to wait for whole 6-pack or should I send it
one-by-one? :)
> Or a more traditional function-like syntax: ${convert(expression,
> optionalHint)} (the "optionalHint" allows to choose a convertor other
> than the default one).
simpler to implement and still fully functional.
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Sylvain Wallez wrote:
>>
>>> This is an interesting idea, which could be even more useful if the
>>> convertors were able not only to produce strings, but also XML
>>> snippets for output-only data. For example, we may want an email
>>> address to be rendered as a <a href="mailto.."> or negative numbers
>>> being displayed in red, or enclosed in parenthesis.
>>>
>>> What that means is that a convertor should be able to do the
>>> following conversions:
>>> - string+locale --> object : parsing request parameters
>>> - object+locale --> string : producing the value of an input
>>> - object+locale+channel --> xml fragment : producing the output view
>>> for a particular channel (html, wap, fo, etc).
>>
>>
>> If I would be able to choose convertors in the template (I mean on the
>> same page render model entry in plain text and pretty printed) it
>> would solve a LOT of my rendering problems. If convertors were
>> pluggable I could also choose which convertor I would like to use in
>> template itself.
...
>> How would this converters be plugged into template language? As
>> components in cocoon.xconf?
>
>
> Don't know yet. This is a [RT]! Maybe JXTG snippets for the
> object+local+channel --> xml fragment conversion?
Reminds me of XMLizer component. The only difference is, instead of InputStream
it should work on arbitrary objects:
public interface XMLizer {
String ROLE = XMLizer.class.getName();
/**
* Generates SAX events from the given object
*/
void toSAX(Object object,
(*) String mimeType,
String systemID,
ContentHandler handler)
throws SAXException, IOException;
}
(*) Instead of mimeType some other kind of parameter might be needed
Vadim
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>
>> This is an interesting idea, which could be even more useful if the
>> convertors were able not only to produce strings, but also XML
>> snippets for output-only data. For example, we may want an email
>> address to be rendered as a <a href="mailto.."> or negative numbers
>> being displayed in red, or enclosed in parenthesis.
>>
>> What that means is that a convertor should be able to do the
>> following conversions:
>> - string+locale --> object : parsing request parameters
>> - object+locale --> string : producing the value of an input
>> - object+locale+channel --> xml fragment : producing the output view
>> for a particular channel (html, wap, fo, etc).
>
> If I would be able to choose convertors in the template (I mean on the
> same page render model entry in plain text and pretty printed) it
> would solve a LOT of my rendering problems. If convertors were
> pluggable I could also choose which convertor I would like to use in
> template itself.
>
> Lovely
:-) More polish beer!!!
> How would this converters be plugged into template language? As
> components in cocoon.xconf?
Don't know yet. This is a [RT]! Maybe JXTG snippets for the
object+local+channel --> xml fragment conversion?
> About syntax in JXTG: Would
> ${convertor-name:expression:formatting-info} be enough?
Or a more traditional function-like syntax: ${convert(expression,
optionalHint)} (the "optionalHint" allows to choose a convertor other
than the default one).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> If I would be able to choose convertors in the template (I mean on the
> same page render model entry in plain text and pretty printed) it would
> solve a LOT of my rendering problems. If convertors were pluggable I
> could also choose which convertor I would like to use in template itself.
Something wrong went with second sentence. I mean if the convertors for CForm
were pluggable one wouldn't have to use JXTG template.jx for CForms just to
render values differently.
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> This is an interesting idea, which could be even more useful if the
> convertors were able not only to produce strings, but also XML snippets
> for output-only data. For example, we may want an email address to be
> rendered as a <a href="mailto.."> or negative numbers being displayed in
> red, or enclosed in parenthesis.
>
> What that means is that a convertor should be able to do the following
> conversions:
> - string+locale --> object : parsing request parameters
> - object+locale --> string : producing the value of an input
> - object+locale+channel --> xml fragment : producing the output view for
> a particular channel (html, wap, fo, etc).
If I would be able to choose convertors in the template (I mean on the same
page render model entry in plain text and pretty printed) it would solve a LOT
of my rendering problems. If convertors were pluggable I could also choose
which convertor I would like to use in template itself.
Lovely
How would this converters be plugged into template language? As components in
cocoon.xconf?
About syntax in JXTG: Would ${convertor-name:expression:formatting-info} be
enough?
--
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: [RT] Attribute Rendering and CForms Convertors
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Bart Molenkamp wrote:
>
>> I've also been thinking about a simple method for displaying object
>>
>> instances of different classes. E.g. I get an object from the flow
>> layer, I need to decide how to format it. Instances of class "A" are
>> formatted differently than instances from class "B". Now, this could be
>> done using <jx:choose>, but that doesn't make the code more readable:
>>
>> <!-- is object instanceof MyClass -->
>> <jx:when test="object.getClass().getName() == 'com.MyClass'">
>>
>> Even worse when you want to check if it is instanceof an interface:
>>
>> <!-- is object instanceof MyInterface -->
>> <jx:when
>> test="${java.lang.Class.forName('com.MyInterface').isAssignableFrom(
>> object.getClass())}">
>>
>>
> I don't know your use cases, so maybe not the following is applicable
> at all, anyway:
>
> In the (often cited on this list) article: Enforcing Strict Model View
> Separation in Template Engines, by Terence Parr
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, a number of
> rules for strict separation between model and view are given. One of
> them is that the view shouldn't make any assumptions about data types
> of the model data. The view should only get displayable strings.
I don't agree with this rule as, in order to avoid the view to know
about the model, it requires the model to know about the view. IMO, the
view should be given the necessary pointers to access the model data it
needs. The granularity of these pointers is the key point that has to be
chosen wisely.
Your convertor proposal below can be a good way for the controller not
to know too much about the view needs and for the view not to depend too
much on the implementation details of the model.
> If one start to depend on data types as in your code above, the
> template files must be supported by programmers rather than web
> designers. And the separation of concern between view and model start
> to get entangeled. Ok, knowing what Terence Parr _don't_ want us to do
> is not very helpfull ;)
>
> As a solution to the problem he sugests MVCR
> (Model-View-Controller-Renderer), where the renderer is responsible
> for converting (Java) data types to displayable strings. The renderer
> can be responsible for localization of numbers etc as well. The
> renderer is an extra step between model and view.
>
> The simplest possible renderer is to just implement toString() in the
> classes one is going to access in the view. But a better SoC is to
> have a separate rendering component. In this case the object from the
> model is first accessed by an expression in a suitable expression
> language and then the object is rendered to a displayable string by
> the rendering component and at last the displayable string is emited
> by the template engine.
>
> So, how would the rendering component work? I think that we basically
> could reuse and extend the Convertor idea from CForms. The renderer
> check the type of the input object (and possibly the locale) and
> applies the apropriate convertor. The coupling between object type and
> convertor is decribed in a configuration file, much as in the form
> definition in CForms. It should also be easy to use custom converters,
> for own data types.
>
> Typically one can reuse the same rendering configuration file for all
> templates.
>
> ---o0o---
>
> I think the renderer component idea could give a better SoC in CForms
> as well. I have had a feeling that data type convertion is not a
> natural part of the model (form definition) for a while. A problem is
> that conversion configuration must be repeated each time the data type
> is used.
The repeated configuration is a problem that will be solved once we have
the ability to define widget types and repositories [1].
> Ok, the idea is as follows: we have a converter component, that is
> like the renderer component above, but bidirectional. I.e. both
> rendering: data type -> displayable string and input conversion: input
> string -> data type. The converter is configured in the same way as
> described for the renderer above.
>
> The convertor is used as a step between the form instance and the view
> for rendering the data types. And between the request object and the
> form instance during the population of the form instance.
>
> Typically only one convertor configuration is needed for all ones
> forms. And we could distribute a localized default convertor
> configuration with Cocoon.
>
> ---o0o---
>
> So, the basic idea is to factor out the type conversion functionallity
> from CForms and make it available for all rendering and input handling
> needs in Cocoon.
This is an interesting idea, which could be even more useful if the
convertors were able not only to produce strings, but also XML snippets
for output-only data. For example, we may want an email address to be
rendered as a <a href="mailto.."> or negative numbers being displayed in
red, or enclosed in parenthesis.
What that means is that a convertor should be able to do the following
conversions:
- string+locale --> object : parsing request parameters
- object+locale --> string : producing the value of an input
- object+locale+channel --> xml fragment : producing the output view for
a particular channel (html, wap, fo, etc).
WDYT?
Sylvain
[1] http://wiki.apache.org/cocoon/WoodyScratchpad
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }