Jonas Ekstedt wrote:
On Wed, 2004-11-17 at 10:25 +0100, Daniel Fagerstrom wrote:
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 m
On Wed, 2004-11-17 at 10:25 +0100, Daniel Fagerstrom wrote:
> 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
w
Bruno Dumon wrote:
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.
*
*
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:
How about an interface like this:
public interface Convertor {
public String getId();
public void setId(String id);
public Class getTypeClass()
On Wed, 2004-11-17 at 09:52 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
> > 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:
> >
> >
> >
> >${tas
Jonas Ekstedt wrote:
On Sun, 2004-11-14 at 22:57 +0100, Daniel Fagerstrom wrote:
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
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:
What I meant was that in the scenario
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 r
Jonas Ekstedt wrote:
On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
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" sam
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
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:
> >>>
> >>>
> >>
> >>
> >>
> What I meant was that in the scena
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:
> >>>
> >>>
> >>>
> >>>
> >>
>
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:
>
> >
> > How about an interface like this:
> >
> > public interface Convertor {
> >
> > public String getId();
> >
Jonas Ekstedt wrote:
On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Jonas Ekstedt wrote:
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
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:
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 req
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.
> *
>
On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote:
> On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>
> How about an interface like this:
>
> public interface Convertor {
>
> public String getId();
> public void setId(String id);
> public Class getTypeClass();
>
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:
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 pre
On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
> > Jonas Ekstedt wrote:
>
>
>
> >> 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 populatio
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:
> >
> >
>
>
>
> >>>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
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 the
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Jonas Ekstedt wrote:
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
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
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 se
Sylvain Wallez wrote:
Jonas Ekstedt wrote:
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
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
Jonas Ekstedt wrote:
On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
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
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
> >>
>
> > How about an interface like this:
> >
> > public interface Convertor {
> >
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 co
Jonas Ekstedt wrote:
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
CForms Convertor Integration
How about an interface like this:
public interface Convertor {
public String getId();
public void setId(String id);
public Class getTypeClass();
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
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.
> *
>
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
Jonas Ekstedt wrote:
On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
Something like ${bean.startDate} or would
use default renderer. Something like ${bean.startDate?class=emph} would point that other convertor is
needed.
I've implemented something similar to this and would be ve
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.
On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
> Something like ${bean.startDate} or would
> use default renderer. Something like ${bean.startDate?class=emph} value="${bean.startDate}" styling="emph"/> would point that other convertor
> is
> needed.
I've implemented something similar
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 configuration
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
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
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 n
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-onl
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
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 you
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
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 a
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
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 t
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
JavaBean
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
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
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. W
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 consist
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 fie
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 comple
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
Ralph Goers wrote:
agree to all
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
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 repres
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 en
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 vi
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
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:
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 conver
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.
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
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-onl
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
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 : producin
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 or neg
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
fo
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
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
Jonas Ekstedt wrote:
On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
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 th
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 or neg
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 or negative numbers
being d
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 templa
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 or negative numbers being displayed in
red, or e
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
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
> e
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 ->
da
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. W
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 ->
da
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
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
d
80 matches
Mail list logo
