I think providing a default behaviour is always good. Allowing it to be overridden it's icing on the cake! :-)
So, I would think the optional script parameter for the validation would be very nice indeed! Looking at the component source it looks pretty forward too, just separate the AjaxScript.script in two, and the one witch is the validation is changed from an infected property to a parameter, right? On 4/14/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > I think the default client side validation is definitely an issue. I was > originally thinking about taking it out altogether, but allowing it to be > an > optional @Script parameter (that ~only~ does validation) isn't such a bad > idea either. > > On 4/14/06, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > > > But for validation you should replace the form's Validation delegate > > (currently it is AjaxValidationDelegate for Tacos). > > > > -- > > Ing. Leonardo Quijano Vincenzi > > DTQ Software > > Web Application Design and Programming > > http://www.dtqsoftware.com > > > > > > Pedro Viegas wrote: > > > Hi list, > > > > > > I'm building my own customized component library so that I get a > default > > > custom look and feel and behaviour in my Tap applications. > > > Naturally I started with the Tacos library as my main component > source! > > :-D > > > I also have as my goal to be able to abstract my applications from > these > > > component library's evolution, having a middle layer in with I can > > abstract > > > the application from component changes but nonetheless being able to > > enhance > > > and take advantage of their new features in a standard way adding > > default > > > features and behaviours to my components, witch will enhance the > > > applications without needing to be updated as much as possible. > > > > > > I've been encapsulating some of the Tacos components I need setting > > default > > > values to some properties, providing default listeners, renderers and > > > datasources (HiveMind services) to them. > > > > > > I'm currently trying to customize AjaxForm. I'm a bit new to tapestry > so > > > forgive me if these questions are silly! :-( > > > What I'm trying to do is, for the moment two things: > > > > > > 1. Change a little something in the JavaScript layer so the > > validation > > > messages appear after the referenced input and not before has > > AjaxForm does. > > > 2. Provide defaults to some properties like effects for instance. > > > > > > Well, I've successfully achieved both, but I'm not at all happy with > > what I > > > had to do. > > > > > > I basically extended the "net.sf.tacos.ajax.components.AjaxForm" in my > > own > > > abstract component class for any overriding or new features I might > need > > > (none so far). > > > I them created my own "Form.jwc" in with I basically *sigh* COPIED the > " > > > AjaxForm.jwc" contents into! Which is.. horrible! :-( > > > I did this because I needed to provide a new script asset overriding > the > > > default "AjaxForm.script" and couldn't think of another way to do > this. > > > > > > I must be a newbie really. I'm sure there is a way to override this > > without > > > having to do this. > > > Can anybody give some pointers? > > > > > > I will need to do these things very often if I carry out my wishes to > > build > > > on top of several component libraries my own customized and extended > > > component library. > > > If I have to do it like I did this one I will have a painful > experience > > in > > > maintaining it as new releases of the underlying libraries are > released, > > > having to one after another release to copy the jwc's from the > sources. > > > One other thing is the JS script. I will also have to copy this one > > every > > > new version just to change the "...Before.." to "..After.." in the > dojo > > > invocation. > > > Could we not render the JS programatically and by suppliyng a > parameter > > > decide where we want to add the validation message? > > > I've not investigated that much the full AjaxForm code to see if it > > would be > > > hard, but doing it in an extended class (as I think would be the only > > way > > > possible) would keep the need to create a copy of the jwc file, right! > > Not > > > good! > > > > > > Thanks in advance, > > > > > > > > > -- > > > Pedro Viegas > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://opennotion.com > > -- Pedro Viegas