On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
<ricardo.ekm.lis...@gmail.com> wrote:
> Hi all,
> We've just finished with success a wicket project for a large online
> retailer. I think wicket is the best framework out there, but as any other
> project there is room for improvement. I will talk about some topics bellow,
> I hope it can help in some way.
>
> - Separation of corcerns
> I think we could get a better separation of concerns if page class were
> focused more in behavior and html were more focused in display (or view).
> What I mean is, some times we have components that the main purpose is to
> add behavior, and we have to add extra markup just to satisfy wicket 1:1
> mapping. Take CheckGroup for exaple, it is a component focused on behavior,
> even though we have to add a reference to it in HTML.
a redesigned CheckGroup is welcome, but that component is the
exception and not the rule.
> When creating composite input fields (like date), the usual way is to create
> a panel even if you are not interested in reusability. A interesting aproach
> is to insert a hidden text field in HTML mapped to a component that controls
> other components input. It makes easier to integrate with designer and to
> preview in browser. If we didn't have this limitation the hidden input would
> not be necessary and the development of behavior focused components would be
> easier.
i dont really understand this..the usual way would be to extend a
FormComponentPanel, not a Panel. are you saying that because the Panel
derivatives are just a <div> in the markup it makes it difficult for
the designers?
> One thing that bothers me is when our designer move things around in HTML
> and we get "added a component in code but forgot to reference it in the
> markup" error, because of component hierarchy. Html tags position is a view
> problem not a behavior problem, so why bother in java?
it *is* a behavior problem. markup is what drives the rendering order
so if you move things around and change the nesting order of
components then you can have a component that is a child of another
render *before* the parent which will cause things to go seriously out
of whack.
in my company the designers understand that they cannot change the
nesting of tags with wicket:id attributes, it took an hour to explain
it to them, and we have not had any problems since. in practice, there
is no need to do that often anyways...
> Another issue, is when we want to change the class of a div, for example,
> and have to change our whole page hierarchy in java, just to manipulate that
> tag.
you dont have to change the hierarchy, just make the component
attached to that div a "transparent resolver" by overriding
isTransparentResolver() and returning true.
> So I think a hierarchy more focused on components behavior (for example
> taking care of inherited models and inputs), rather than tags position in
> HTML would be better. This would make wicket more flexible and easier to
> work with.
once again, this is only a problem when you change the *nesting* of
components. if a component can be safely moved outside the parent,
then why is there a nesting to begin with? why arent the two
components siblings? the *nesting* is usually there *because* there is
a functional requirement.
here is a simple usecase:
webmarkupcontainer admin=new webmarkupcontainer("admin") { isvisible()
{ return user.isadmin(); }};
admin.add(new link("delete") {...});
the code is pretty much self-explanatory, now the designer takes the
delete link and moves it ouside the wicket:id="admin" tag. in your
vision this would work, but now the designer has completely
circumvented security the developer has put into place.
> - Too many finals modifiers
> It's hard for a API or framework designer to foresee all uses and unxepected
> situations its users may face in day to day development. Final modifiers
> places a additional challenge when facing these situations. In project were
> deadlines are in place, there is little room for submiting a request and
> waiting for a new version to be released. Furthermore, unfortunately, it's
> not possible to mock final methods making it harder sometimes to test wicket
> related classes/components. What we had to do internally, is to have our own
> version of wicket, mainly to remove final modifiers when necessary, a clear
> violation of open/closed principle.
there is a trade off here. the final modifiers allow us to change
things below without breaking the api because final methods do not
expose a contract. when we make a code change inside a final method we
do not have to think about all the users out there who might have
potentially overridden the method in their apps and we have to make
whatever change backwards-compatible.
in short, the upgrade path with final methods looks like this:
1.4.0,1.4.1,...,1.4.8,1.4.9
and the path without final methods would look like this:
1.4.0,1.4.1,1.5.0 (api break),1.5.1, 1.6.0 (api break), 1.7.0 (api break)
and because we are changing contracts the api break would most likely
not be compile time, so you would have to scour through release notes
and see if you have overridden any of the specified methods that now
work differently.
which one is better?
> - Ajax
> Wicket offers no stateless ajax
we may work on a stateless ajax in the future, for now it is really
not that hard to use a third party library.
> and often changes HTML id, which makes
> harder to integrate with a 3rd party ajax framework.
wicket only changes ids that belong to components, and that is only to
make sure they are unique. wicket does , however, offer a way to
override the id to whatever you want by calling setMarkupId(..)
the proper way to integrate with third party libraries is to pass them
ids by calling getmarkupid()
> Is there any hope for
> constructor change?
what constructor change is that?
-igor
>
> Please let me know your thoughts, keep up the good work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
