Well, you're welcome to put a release out.
Small update: I've been working for the whole weekend on the validation stuff, and found a bunch of bugs/ wrongs framework thingies along the way. I did not plan for this weekend to do nothing but programming, but so be it. I think the changes are really important as the state of things kind of - well, - sucked (no offence pls; some things are my fault as well ;).
Things I found:
- The persistence manager tried to get cookies for all components. Property persistenceEnabled was never read.
- The persistence manager kept a reference to the request cycle. This clearly is wrong, as the persistence manager is stored with the form, which is stored in the session. This *might* be the reason for the strange session exp problem you guys had. I had some strange behaviour with a session exp, but after the fix it never came back.
- I also changed the persistence manager to an interface; people can now use their own if they are not happy with the default. This is relevant (I think) as people might want to try to merge info into one cookie instead of doing calls for each component. That said, I am not much of a cookie expert, but I think there's no harm in using an interface here.
- Another issue I had (not able to sign out with Firefox) and that I mailed about two weeks ago is solved now as well.
- Allthough validators were there to be used to catch errors that break the model (e.g. when using a PropertyModel with an object that has an Integer property), after validation all values were applied to the models anyway. Resulting in stacktraces even if errors were found in time.
- Like I stated in an earlier email, validation stopped at the first error.
- It was not possible to track what component registered what error. There's many cases where you could want this information
- As model changes were applied before validation there was no way to avoid conversion exceptions anyway.
- The feedback panel should be able to handle more than one message, and should use class attributes instead of the font tag. I improved it a bit, but I think this component can be much better still.
- ... well you get the idea ;)
The new setup:
- New class UIMessage represents a message that is meant to be rendered on the page. A UIMessage has a 'level' property that works much like Log4J (INFO/ ERROR/ etc.). Also UIMessage keeps a reference to the reporting component.
- New class UIMessages holds these messages and has a bunch of usefull methods that work on the message list (like getting all messages for a certain level and above, getting a useful IModel, getting all reporting components etc.). UIMessages is completely managed by Wicket (works with a ThreadLocal) and can not be instantiated by framework clients.
- New class ValidationErrorMessage is a specialization of UIMessage meant to be used with validation and that has fixed level ERROR..Besides keeping a reference to the reporting component, it also keeps a pointer to the input that caused the error to be reported.
- The validate method of interface IValidator now additionally has parameter 'input' (of type Serializable; as arrays etc can be input as well). This input should be used by the validators instead of having the validators to get their parameters from the request directely.
- Interface IValidationErrorHandler now has method validationError(final UIMessages errors) instead of validationError(final String message).
- FeedbackPanel now works with a Table (soon to be ListView) that prints out a ul with an li for each message. It uses classes (ComponentTagAttributeModifier works really neat here) for customization.
The validation process now is roughly like this:
When a form is submitted, method formSubmitted first calls the validate method. In validate all child (form)components are called for validation, and for each component the IValidator interface method is called. If that call returned a ValidationErrorMessage that message is added to the current threads' UIMessages object. Also, the model of the reporting component will be temporarily wrapped by a decorating IModel that holds a reference to the original model, but serves the input as its model object instead of the original model object. Hence, components that reported validation errors will render the input they got from the request without this having nasty consequences for the actual models. After rendering, the original models are put back on these components. Note that in case of validation errors, handleSubmit will not be called (it has allways been like this), so there should be no problems with form components trying to do something usefull with their models.
I just checked in the code. Before I did that, I tagged the core and examples (as V_27_11_2004), so if people are really unhappy with the changes, it's easy to roll back. I hope you all like the changes. Sorry that I committed them before waiting until everyone has had it's say, but I think these changes are well worth a closer look. Please take a look at the CD example to get an idea of how the validation can work. Again the ComponentTagAttributeModifier works great here as well.
Finally time for bed now, Eelco
Martijn Dashorst wrote:
I disagree with postponing the release this weekend. I think it is necessary to put out the current CVS status as a weekly release. Just flag it as such. This will help people to see progress. Between the latest release and now much has changed.
If you still haven't finished these tasks next weekend, will a release be postponed again?
I really don't like to have to have the wicket project checked out in the same workspace as my real life project and have the project depend on that as this forces other people to also check out wicket.
Release small and often hasn't hurt many projects.
Martijn
Eelco Hillenius wrote:
Ok, it looks like I'm not gonna make it either... I am working on the validation workings of Wicket (I mailed about that earlier this week). I am allmost done with that, but want to let it rest for a day and see if I still like what I came up with, and then - ofcourse - I want to make a proposal about those changes on this list. I would really like to have both the ListView changes and the validation changes in this next release.
So, everyone, let's go for a release next week(end).
Does anybody think there will be a need for core API changes after these changes? If not, I propose to fix the API and move to beta. I think it would be great to have our first beta by the end of this year.
I think the first beta should at least have:
- A stable API; it's still beta, so API changes can happen, but we should be commited to implement drastic changes if any before that.
- A user manual that's in sync with the current state of the examples and core.
- The new look (site/ logo)... I know Martijn is still working on this in his spare time.
- ... ?
Agreed/ more must haves?
Regards,
Eelco
Juergen Donnerstag wrote:
It will not be ready today. Hopefully next week.
Juergen
On Sat, 27 Nov 2004 11:29:56 +0100, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
All,
I would like to bring out a new release this sunday. If anyone has stuff
outgoing (Juergen with the ListView stuff?), please commit today, or let
me know that it will not be for this release.
Cheers,
Eelco
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
