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
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
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
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
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
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
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.
*
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
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();
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.
*
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
On 05.11.2004 11:19, Leszek Gawron wrote:
Terence Parr sugests that test like $bloodPressure120 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
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
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
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
Ralph Goers wrote:
snipagree 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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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 -
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
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
77 matches
Mail list logo
