and where is this more OO?
-igor
On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
<martin.maku...@koodaripalvelut.com> wrote:
> I vote +1 for more OO Wicket. Way to go Ricardo!
>
> **
> Martin
>
> 2009/12/23 Ricardo Mayerhofer <ricardo.ekm.lis...@gmail.com>:
>> Hi Igor,
>> Thanks for your response. Here goes my observations:
>>
>> Em 22/12/2009 14:41, Igor Vaynberg escreveu:
>>>
>>> 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.
>>>
>>>
>>
>> Yes, but how do we deal with the requirement of all components having a HTML
>> representation? The same happens with RadioGroup, even with wicket-1055
>> solved, the HTML reference is still there.
>>
>>>> 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?
>>>
>>>
>>
>> You're right, I meant FormComponentPanel. I think it would be better not
>> being constrained to have a separate markup just because server side
>> processing will be different. After all in HTML terms, a composite input is
>> the same as a single input. Another example of unecessary coupling IMO is
>> that text area and input text fields are mapped to different components,
>> even behaving the same.
>> Even if there are internals when manipulating one or another, I think it
>> should be handled by wicket because for the programmer it makes no
>> difference.
>>>>
>>>> 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...
>>>
>>>
>>
>> IMO learning how to deal with a restriction, isn't better than removing that
>> restriction. Even if it doens't happen often, I would be happier if it never
>> happens :)
>> Render order seems a wicket internal concern to me not a business or
>> application behavior concern.
>>>
>>>
>>>>
>>>> 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.
>>>
>>>
>>
>> They have a functional relationship, so no matter where delete link is in
>> HTML, it should be invisible. This has a aditional advantage that I do not
>> need to map admin to HTML, and can group another admin functions in the same
>> component, even if they're scattered.
>>>>
>>>> - 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?
>>>
>>>
>>
>> Being able to overcome a problem is a need required by the current project,
>> which final may impose a additional challenge.
>> Upgrades, on the other hand, are usually planned process, in which are
>> considered possible problems or API changes.
>> I think spring is a good example in this area. It has a pretty good backward
>> compatibily, and use very few finals.
>>
>> About contracts, I think that they should be specified in terms of
>> interfaces, not concrete classes. If you depend on concrete classes, it's
>> natural that they evolve and may break your integration.
>>>>
>>>> - 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()
>>>
>>>
>>
>> Many of things I raised (or all of them) have solutions in wicket. But I
>> think it's best when the framework solves the problem, rather than doing it
>> myself. That's why we use frameworks in the first place.
>>>
>>>
>>>>
>>>> Is there any hope for
>>>> constructor change?
>>>>
>>>
>>> what constructor change is that?
>>>
>>>
>>
>> From the discontinued 2.0.
>>>
>>> -igor
>>>
>>>
>>
>> Thank you for your feedback.
>>>
>>>
>>>>
>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
