Sylvain Wallez wrote:
Marc Portier wrote:
sorry Sylvain this slipped my attention, haven't been deep enough into validation and event aspects to make well thought off counter proposals (not saying that they are needed, but I do understand it helps if someone at least every now and then confirms your thinking)
upfront you already have my utter trust and blessing, but lemme get into it a bit at least
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Now I think that every widget should be able to have validators. Some use cases:
- on a form, to perform some inter-field validations, and even application-level validation if the means to access application data is given to the validator.
- on a repeater, to check e.g. uniqueness of some values among rows
- on a group (i.e. "class", "struct", etc) where some validation between the various widgets of the group may be wanted (actually, a form is a group)
makes sense
The current ValidationRule interface is not suited for this, as it is really tied to widgets that have a value, which neither form nor repeater have.
hm, maybe they should?
the introduction of group has got me thinking about that in fact... it would be kinda swell if group.getValue() would yield a hashMap :-)
Mmmh... IIUC, you're actually replacing group.getWidget("child-id") by ((Map)group.getValue()).get("child-id"). Does it bring some real benefits?
that's what I said: it just sounds nice logic and nice, but I have no real life use case requiring it, so it's mainly an academic observation here and now.
your remark on widgets that do not have values just invited me to express this thought I had some time ago...
Anyway, having a Validator interface acting on Widget doesn't require widgets to have a value nor prohibits it.
sure.
after all the widget-instance-tree is pretty much that in some way, plus links back to their definitions and such, it's still pretty much thinking out loud, but in general something dual to the processing of requestparameters to produced some grouped value Collection seems generally usefull (but that is an academic observation since I'm not holding onto real use cases yet)
So my idea is to introduce a generalized "WidgetValidator" with a single "validate(Widget w, FormContext ctx)" method. The current ValidationRule implementations we have today can then simply become subclasses of a "FieldValidator" abstract class.
We also have to see how validators can have knowledge of the surrounding application environment to perform application-level validation. A discussion between Marc and myself a while ago came to the conclusion that we may use pseudo-fields in a form as value holders, as it would make the contract between the form and the application more visible than by adding attributes to the Form object.
ouch this is really a LONG time ago, no?
Well, september 2003 isn't that far away ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106398494806681&w=2
yep, that's the one,
I was mainly regretting that I haven't used the intermediate LONG period to actually try out more of the ideas in there...
We were discussing the ability for event handlers to access application data. The proposals for this included adding attributes on widgets or adding hidden widgets. Rereading this, I remember that I preferred to add attributes to widgets, but no I think hidden widgets, or better specialized "app-data" widgets would better expose the communication contract between the form and the application.
while I still think that just plain callback functions are a better way to callback into the application-flow
there lays the real need for that info anyway, so why use the intermediate step of the form-model that then needs to be read out by the flowscript?
maybe some function-pointer idea like the one Chris recently added for the cleanup of resources in sendPageAndWait could help out?
What do you think?
+1 makes sense, adds stuff without breaking things
(although it is changing some interfaces, but that is why we have this block still marked alfa after all)
Actually, it does change things, since validators are no more properties of the datatype, since they apply on all widgets and not only fields. This means that <wd:validation> in fields will have to move as a sibling of <wd:datatype>.
But no fear, as we can keep the two locations for a while and deprecate the use of <wd:validation> inside <wd:datatype>.
yep, that is what I was saying:
- not functionally breaking features we had before, right?
- but rather changing/relocating to more logically allow new (related) features
so IIUC the same things as before are still possible, but through slightly different use of the API or definition files.... again: I think we are still in alfa phaze for woody precisely because of these relocations happening, no?
I know alfa sounds bad to some people, but I'ld really prefer us to dwell in this stage some longer then to see us building overly complex constructions for the sake of backwards compatibility... AFAI am concerned we need this flexibility still for some time to come...
Above is also why I like the approach of adding checks and issue log-errors for things that changed according to the previous 2-3 stable 2.1.x releases of cocoon... not copletely sure yet what our policy should be on evetually removing those again... (nor am I in a position to hint how much longer our dwelling should take)
No answer on this? If no one objects, I will implement it as I really need it now.
go ahead.
Yeah!
Sylvain
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
