Eelco,
Thanks so much for your input! I am still seriously
learning Wicket now and will see if I will change my
mind.
BTW, what is the best Wicket example website? I often
have many questions when reading tutorials with simple
examples. I wonder Wicket can do or how do more
callenging/complex situations that I can easily handle
with Spring MVC.
Regards,
David
--- Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > 1. It is too much coding. Anybody used Valang in
> > Spring Module? By using Valang, the validation
> code is
> > much clean and a lot fewer and you dont need to
> create
> > a class simply for this simple validation.
>
> The example you quoted is an example of a reusable
> validator that
> checks the values of two components with each other.
> It's probably a
> rare case to create a reusable validator for it, as
> you can achieve
> the same thing with fewer lines of code by just
> performing the check
> on your form's or button's submit method and then
> setting the error on
> failure. But the choice is yours whether you want
> the validation to be
> reusable (which also means it will be easier to move
> around in your
> code) or whether you just implemented quick and
> dirty (like I often
> do).
>
> Btw, team members, this comment can be found in
> IFormValidator:
> * TODO post 1.3: remove validate(form) *make
> IFormValidator extends
> IValidator where IValidatable's
> * value is form.modelobject and error reports on
> form - that way
> IBehaviorProvider can extend
> * IValidator
>
> > 2. Valang covers both client AND server-side
> > validation. Please note that client-side
> validation is
> > equally important as server-side's. I feel it is
> a
> > must for web apps in terms of user experience.
>
> It is very important that the server-side validation
> is robust, since
> the client-side can be messed with.
>
> Whether client-side validation is important
> depends... I typically use
> Ajax if I want checking on the fly. Very easy to
> implement using
> Wicket.
>
> But if you want client-side validation, you can
> create a combined
> validator and behavior (that would contribute the
> JavaScript code to
> the client), e.g. by letting your validator
> implement
> IValidatorAddListener and adding the behavior
> (possibly itself) to the
> component in the onAdded method.
>
> Would be fun if someone would pick this up and
> extend some of the
> simple validators we have with this.
>
> > 3. In Valang + Spring MVD, you have all the
> validation
> > code for a form in one place in stark contrast to
> > spreading it in "controller" code as in Wicket
> and
> > mixing validation code with visual manipulation
> code.
> > Valang's way is much easier to understand and
> > management.
>
> I don't know Valang, so I'm not sure what you mean.
> Anyway, you have
> plenty of choices to hide validation code if it
> bothers you. Examples
> are the automatic assignment of validators based on
> Hibernate
> annotations like we're doing in the project I work
> on (done via
> IComponentOnBeforeRenderListener), or custom
> components that assign
> validators to self in their constructors.
>
> Personally, I think Wicket's solution to validating
> components is
> quite nice as long as the validation is related to
> one component. If
> not (multiple components are non-related), it gets
> more messy, but I
> can't imagine that would be much better in other
> frameworks.
>
> > So in terms of elegance, productivity,
> management,
> > ..., I am not sure Wicket's is right.
>
> I think it is if you use your creativity and OO
> skills to make it fit
> your style.
>
> > Can Wicket provide a better solution?
> >
> > I would like to share my concern regarding the
> > Wicket's WebPage, where you put a form's code for
> some
> > visual aspects, validation, ajax, etc. in one
> place. A
> > big object. I feel it is too ambitious and it
> looks
> > like spaghetti code and mixes concerns/modules in
> one
> > place. Comment?
>
> Much to debate here, and there are plenty of
> discussions of the pros
> and cons to be found on the internet.
>
> You don't have to put everything in place; again use
> your OO skills to
> make it more elegant. Furthermore, the fact that so
> much is statically
> typed Java code that is also stateful makes that it
> is easy to
> maintain/ refactor/ navigate/ explore/ debug
> compared to declarative
> frameworks. Declarative frameworks often can result
> in less code, but
> typically only for relatively simple things, and you
> won't get any of
> the advantages of working with statically typed
> code. Also, a
> declarative framework - a DSL in fact - can never be
> as flexible as a
> general-purpose language. Wicket is very flexible
> because of that.
> Whether limitations of declarative frameworks hit
> you of course
> depends on what you're doing with it.
>
> Good luck,
>
> Eelco
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
