On 3/8/07, David Leangen <[EMAIL PROTECTED]> wrote:
This is actually something I'm kinda struggling with.
In our model, the "biz logic" is the query. So, for instance, if I have
two radios and a group of checkboxes:
( ) Any colour
( ) Choose colours
[ ] Blue
[ ] Red
...
If "Any colour" is chosen, then this produces one kind of query (where
choosing colours is irrelevant). In that case, the checkboxes must be
disabled. However, if "Choose colours" is chosen, colours become
relevant, so the checkboxes are activated.
So, is this "biz" or "ui" logic?
the part that enables and disables components is ui logic. there is no need
to break that out into somewhere else.
the logic that validates the bean constructed by the ui is business logic.
but there are aguments to keep validation as close to the ui as possible
because its easier to map and is closest to the input - so that one is up
for grabs i suppose. this is why i decoupled validators in 2.0 - so
potentially you can use the exact same validator in your service layer and
in the ui layer.
Or, worded differently, does this go into the controller or directly
into the wicket component?
i would put this into the wicket component and call it a day. if you are
planning on having some other interface these beans can be constructed from
then i would consider some sort of validation in the controller.
it would be a good idea if you can initialize some state off the
> pageparameters, be that business state or ui state or both. that way
> you can retain bookmarkability.
Just to confirm:
We would not be _required_ to use PageParameters. Having a lightweight
bean would allow us to "save" the state of the bean in the model, and
therefore to the PageMap, right?
s/PageMap/session/
But, using PageParameters would give us the option of making pages
bookmarkable, right?
bookmarkable pages serve as entry points into the workflow, so if you need
that then yes, but it doesnt mean every page makes sense as an entry point.
In either case, this approach is still valid, so it seems.
Another question:
Say we do want to keep our pages bookmarkable, but we don't want to have
to encode everything in the URL. Say also we don't want to use a db on
the backend. Would it be appropriate to save the beans to the wicket
session?
if its not encoded in the url then where would it be encoded? as i said
bookmarkable pages are entry points so they need to contain all the
necessary state to initiate the workflow. and the only place for that is the
url.
If so:
1. What is an elegant way of doing this? Just a Map(id, object)
that is accessed by the controller?
i would write a converter that can do bean<->pageparameters
2. Is there anything to watch out for? (Such as the map growing to
an incredible size, for example)
if you keep things scoped at a page and pass them from page to page you can
take advantage of wicket's state management so your state wont get too big.
-igor
> i think a lot of users underestimate the power of IModel when you
> implement it directly.
<snip>
> now all you have to do is
>
> LoadableDetachableModel person=new LoadalbeDetachableModel(id);
> new CheckBox(this, "cb", new PersonCheckBoxModel(person));
>
> and everything magically works, hope it gives you some ideas.
Very interesting!
I'll have to give this a try.
Thanks again!
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
