Hunsberger, Peter wrote:
Sylvain Wallez <[EMAIL PROTECTED]> writes:
Now the above sentence is totally contradictory with a previous proposal of me to include the binding into the form definition. Why did I proposed this ? Because in small/medium apps, the one that designs the form is often (
Sylvain Wallez <[EMAIL PROTECTED]> writes:
> Now the above sentence is totally contradictory with a
> previous proposal
> of me to include the binding into the form definition. Why did I
> proposed this ? Because in small/medium apps, the one that
> designs the
> form is often (again, my ow
Andreas Hochsteger wrote:
Sylvain Wallez wrote:
Shared neurons again : re-thinking to my previous post, I realized
exactly what you say. The various model extensions needed by each
layer need to be physically separated (different people, different
files), but must be assembled into a single ru
Sylvain Wallez wrote:
Shared neurons again : re-thinking to my previous post, I realized
exactly what you say. The various model extensions needed by each layer
need to be physically separated (different people, different files), but
must be assembled into a single runtime model.
So actually, w
Marc Portier wrote:
Sylvain,
A bit short on time ATM, I don't want to leave you waiting on some
full lenght reply, so I'm jotting down my wild
catched-while-under-the-shower-thoughts:
I'ld like to make some consensus proposal which in my head (current
vague idea) could be hooked up by making
Sylvain,
A bit short on time ATM, I don't want to leave you waiting on
some full lenght reply, so I'm jotting down my wild
catched-while-under-the-shower-thoughts:
I'ld like to make some consensus proposal which in my head
(current vague idea) could be hooked up by making distinction
between
On Saturday, Aug 2, 2003, at 13:06 Europe/Rome, Marc Portier wrote:
IMO, SoC is more about colaboration then it is about separation?
Absolutely. This is indeed so: once you start the path of enforcing SoC
and you start measuring your architectures in terms of concern overlap
and contract solidit
Marc Portier wrote:
Hi again :-)
just adding some more phylosofical notes on webapp design and
modelling (it is week-end after all, hope you all don't mind me
getting into the meta levels of things)
Nice stuff, Marc. I went through similar thoughts, but through a less
philosophical way (I'
Hi again :-)
just adding some more phylosofical notes on webapp design and
modelling (it is week-end after all, hope you all don't mind me
getting into the meta levels of things)
as explained my feeling is that woody's model should be as decoupled
from the 'template' as it is from the 'backe
Hunsberger, Peter wrote:
Marc Portier <[EMAIL PROTECTED]> writes:
Andreas Hochsteger wrote:
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML
input fields?
We are currently using three input fields for dates
Sylvain Wallez <[EMAIL PROTECTED]> writes:
> Now from a more semantical point of view, AggregateField is something
> I'm not very comfortable with. Let's consider its two use cases :
>
> 1/ Phone number example
> In this example, the displayed form shows only one input box, and its
> value is s
Marc Portier <[EMAIL PROTECTED]> writes:
> Andreas Hochsteger wrote:
> > Hi!
> >
> > A short question comes to my mind, while reading your RT:
> > Is it possible to use data types which are composed of several HTML
> > input fields?
> > We are currently using three input fields for dates (day,
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
I see two solutions for this :
- the messy one (IMO) : add some non-visual fields in the form to
hold the necessary data,
- add a get/setApplicationData() on FormContext so that widgets can
use it during fo
Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
I see two solutions for this :
- the messy one (IMO) : add some non-visual fields in the form to
hold the necessary data,
- add a get/setApplicationData() on FormContext so that widgets can
use it during form.process() if the form
Sylvain Wallez wrote:
Marc Portier wrote:
I see two solutions for this :
- the messy one (IMO) : add some non-visual fields in the form to
hold the necessary data,
- add a get/setApplicationData() on FormContext so that widgets can
use it during form.process() if the form has an associated b
Marc Portier wrote:
I see two solutions for this :
- the messy one (IMO) : add some non-visual fields in the form to
hold the necessary data,
- add a get/setApplicationData() on FormContext so that widgets can
use it during form.process() if the form has an associated binding.
surely I prefe
Andreas Hochsteger wrote:
Hi!
I have to tell you that this thread is really a pleasure.
It's really amazing what 'shared neurons' (like Marc called it) are
possible to do ;-)
I often have the feeling that while reading a message some ideas come to
my mind and recognize that in the next post t
Andreas Hochsteger wrote:
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML
input fields?
We are currently using three input fields for dates (day, month, year)
at our current form solution.
Thanks for clearificati
Andreas Hochsteger wrote:
Hi!
I have to tell you that this thread is really a pleasure.
It's really amazing what 'shared neurons' (like Marc called it) are
possible to do ;-)
I often have the feeling that while reading a message some ideas come
to my mind and recognize that in the next post th
Hi!
I have to tell you that this thread is really a pleasure.
It's really amazing what 'shared neurons' (like Marc called it) are
possible to do ;-)
I often have the feeling that while reading a message some ideas come to
my mind and recognize that in the next post they are already covered.
Per
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
agree totally: that is the crux!
(maybe we should change the binding word: this validation is
business-model specific)
the main thing to note is that this specific validation will also be
executed during the form.process()
a
Andreas Hochsteger wrote:
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML
input fields?
We are currently using three input fields for dates (day, month, year)
at our current form solution.
No, not currently...
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML
input fields?
We are currently using three input fields for dates (day, month, year)
at our current form solution.
Thanks for clearification!
Bye,
Andreas
S
Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Validators currently exist only for datatypes, and not yet for
bindings (this is on my todo list).
yep, some nuance though:
there should be only one validation cycle!
what I mean is:
- we probably do want
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Validators currently exist only for datatypes, and not yet for
bindings (this is on my todo list).
yep, some nuance though:
there should be only one validation cycle!
what I mean is:
- we probably do want to be able to express vali
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
>
>
> >So, actually the Widget Tree is created dynamically when needed.
> Now, is it possible to hook into the building of this tree?
> >
> >
>
> You can write your own WidgetDefinition implementation : you can then
> put any code that wi
Carsten Ziegeler wrote:
So, actually the Widget Tree is created dynamically when needed. Now, is it possible to hook into the building of this tree?
You can write your own WidgetDefinition implementation : you can then
put any code that will be executed each time a form instance will be
cre
Sylvain Wallez wrote:
>
> Carsten, I think you need to know a bit of the internals of Woody.
Yes, definitly!
> For a
> single element of the form definition file, say , 3 classes
> are involved in its processing :
> - FieldDefinitionBuilder : analyzes the element and from its
> attributes an
Carsten Ziegeler wrote:
Marc Portier wrote
I think this has to be changed :) It should be done dynamically when
the form is "rendered".
this is fundamentally different to how it is done now
we seem to think there is some advantage for 'caching' the
form-definition and instantiating th
Marc Portier wrote:
Sylvain Wallez wrote:
Validators currently exist only for datatypes, and not yet for
bindings (this is on my todo list).
yep, some nuance though:
there should be only one validation cycle!
what I mean is:
- we probably do want to be able to express validation-rules by u
Carsten Ziegeler wrote:
Marc Portier wrote
Hmm, ok, caching does not prevent to have some dynamic elements
in it. You can cache, let's say 89%, and 11% are calculated dynamically.
agree, I guess you just need to come up with the obvious case
that makes us understand where to draw the line...
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I think you missed the real meaning of my post : since validators are
pluggable, you can write you own and do whatever you want in it !
Cocoon should provide the most useful and generic implementations,
but it does not loc
Marc Portier wrote
> > I think this has to be changed :) It should be done dynamically when
> > the form is "rendered".
> >
>
> this is fundamentally different to how it is done now
>
> we seem to think there is some advantage for 'caching' the
> form-definition and instantiating the form from
Sylvain Wallez wrote:
Antonio Gallardo wrote:
Sylvain Wallez dijo:
Not a problem, since is just a particular implementation of
Validator. So what about :
Hmm. At the first look it is great for people starting writing from now
the beans! But, ... :(
I see a problem:
think in peopl
Carsten Ziegeler wrote:
Marc Portier wrote:
So what you are adding to the show is that the datatype
(basetype) setting of the widget should be possibly derived from
the binding path into the business object?
Yes.
now (currently) the form-model building happens before the
business object
Marc Portier wrote:
>
>
> So what you are adding to the show is that the datatype
> (basetype) setting of the widget should be possibly derived from
> the binding path into the business object?
Yes.
>
> now (currently) the form-model building happens before the
> business object is there, s
Carsten Ziegeler wrote:
Marc Portier wrote:
there is a sample now doing that, above statement leaves it
unclear if you tried that or not
No, not yet.
if I understand what you are saying, then you would want to have
the form definition (structure, fields, datatypes and convertors)
deduced
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I think you missed the real meaning of my post : since validators are
pluggable, you can write you own and do whatever you want in it !
Cocoon should provide the most useful and generic implementations, but
it does not lock with the provides impl
Sylvain Wallez dijo:
> I think you missed the real meaning of my post : since validators are
> pluggable, you can write you own and do whatever you want in it !
>
> Cocoon should provide the most useful and generic implementations, but
> it does not lock with the provides implementations.
Opps. Yo
Sylvain Wallez wrote:
>
> I think you missed the real meaning of my post : since validators are
> pluggable, you can write you own and do whatever you want in it !
>
> Cocoon should provide the most useful and generic implementations, but
> it does not lock with the provides implementations.
>
Antonio Gallardo wrote:
Sylvain Wallez dijo:
Not a problem, since is just a particular implementation of
Validator. So what about :
Hmm. At the first look it is great for people starting writing from now
the beans! But, ... :(
I see a problem:
think in people that has already to
Sylvain Wallez dijo:
> Not a problem, since is just a particular implementation of
> Validator. So what about :
>
>
>
Hmm. At the first look it is great for people starting writing from now
the beans! But, ... :(
I see a problem:
think in people that has already to many Beans? (This i
Sylvain Wallez wrote:
>
> Not a problem, since is just a particular implementation of
> Validator. So what about :
>
>
>
>
Wow, that's simple! Why didn't I have the idea.
Ok, agreed...for now :)
Carsten
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This calls for binding-specific validators that know both the
application model and the form model. I proposed to add XPath predicates
to the binding for this purpose. E.g :
Business model rejects value for
"foo"
The variables are prede
Sylvain Wallez wrote:
>
> This calls for binding-specific validators that know both the
> application model and the form model. I proposed to add XPath predicates
> to the binding for this purpose. E.g :
>
>
>
>
> Business model rejects value for
> "foo"
>
>
>
> The variables are p
Carsten Ziegeler wrote:
Marc Portier wrote:
there is a sample now doing that, above statement leaves it
unclear if you tried that or not
No, not yet.
if I understand what you are saying, then you would want to have
the form definition (structure, fields, datatypes and convertors)
Marc Portier wrote:
>
> there is a sample now doing that, above statement leaves it
> unclear if you tried that or not
>
No, not yet.
>
> if I understand what you are saying, then you would want to have
> the form definition (structure, fields, datatypes and convertors)
> deduced from the
Steven Noels dijo:
> On 29/07/2003 18:52 Sylvain Wallez wrote:
>
>> And how good it is to see people having so deep the understanding of
>> opensource values and benefits.
>
> ... this being the standard in this fine community. Apart from some core
> values, most of my clue w.r.t. the mix of open
On Tue, 2003-07-29 at 18:31, Sylvain Wallez wrote:
> Bruno Dumon wrote:
>
> >On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote:
> >
>
>
>
> >>As for disposal, the TreeProcessor maintains a list of all Disposable
> >>nodes created by the builders that are disposed when the sitemap itself
> >>i
On 29/07/2003 18:52 Sylvain Wallez wrote:
And how good it is to see people having so deep the understanding of
opensource values and benefits.
... this being the standard in this fine community. Apart from some core
values, most of my clue w.r.t. the mix of open source code, communities
and bus
Steven Noels wrote:
On 29/07/2003 18:17 Sylvain Wallez wrote:
Marc Portier wrote
I do understand this might break some backwards compat stuff, but
the block is labeled 'unstable' and 'alfa' precisely because we know
this is bound to happen
nevertheless Bruno is doing an effort to notify the
On 29/07/2003 18:17 Sylvain Wallez wrote:
Marc Portier wrote
I do understand this might break some backwards compat stuff, but the
block is labeled 'unstable' and 'alfa' precisely because we know this
is bound to happen
nevertheless Bruno is doing an effort to notify the users list of
importa
Bruno Dumon wrote:
On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote:
As for disposal, the TreeProcessor maintains a list of all Disposable
nodes created by the builders that are disposed when the sitemap itself
is disposed (BTW, thanks Carsten for finding that nodes should be
disposed in re
Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain,
This perfectly alligns with how I have been thinking about
extracting and embracing the nice ideas your first RT was bringing
to the scene...
Cool ;-)
it is called 'shared neurons' :-)
my (not Bruno's) planning:
1
On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote:
>
>
> >Currently it is not checked that the value comming from the request is
> >actually in the list. So the list is more of an input-aid then an
> >enum-type.
> >
> >That's also one of the reasons I've moved it out of the datatype,
> >together
Bruno Dumon wrote:
On Mon, 2003-07-28 at 22:15, Sylvain Wallez wrote:
Convertors
--
Convertors (or should it be "converters" ?)
hmm, good point. They seem to be both valid. I seem to have a natural
tendency to write "convertor", but I'm fine with both. I've noticed that
later on i
Carsten Ziegeler wrote:
I have read most of the RT and think I have understand some parts of it.
Now, I agree that keeping the field definitons as short and comprise
as possible is good.
Now - without reading more of all the discussions and looking into
woody - I just wanted to throw in some aspe
On Mon, 2003-07-28 at 22:15, Sylvain Wallez wrote:
> Convertors
> --
>
> Convertors (or should it be "converters" ?)
hmm, good point. They seem to be both valid. I seem to have a natural
tendency to write "convertor", but I'm fine with both. I've noticed that
later on in this mail you've
Hi:
Comments below :)
Carsten Ziegeler dijo:
> Validation
> --
> It's good to have the possibility to define validation in the form and
> at the fields. But in some cases your business objects can
> validate their values as well and you don't want to code it twice.
If we are going to
I have read most of the RT and think I have understand some parts of it.
Now, I agree that keeping the field definitons as short and comprise
as possible is good.
Now - without reading more of all the discussions and looking into
woody - I just wanted to throw in some aspects which I think are
cur
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain,
This perfectly alligns with how I have been thinking about extracting
and embracing the nice ideas your first RT was bringing to the scene...
Cool ;-)
it is called 'shared neurons' :-)
my (not Bruno's) planning:
1/ prep up for a local se
Marc Portier wrote:
Sylvain,
This perfectly alligns with how I have been thinking about extracting
and embracing the nice ideas your first RT was bringing to the scene...
Cool ;-)
It also shows you have a more elaborate (lots of forms?) case at hand
you want to tackle with Woody, so I really
Sylvain,
This perfectly alligns with how I have been thinking about
extracting and embracing the nice ideas your first RT was
bringing to the scene...
It also shows you have a more elaborate (lots of forms?) case at
hand you want to tackle with Woody, so I really think your
proposed rationali
Hi all,
One week after my first RT about Woody, after having read Marc and
Bruno's answers and after lots of background thinking high in the
mountain, here comes some more about Woody. I have abandoned (for now?)
my idea of "form-defining template" which seems not so intuitive nor
realistic, a
64 matches
Mail list logo
