On Wed, Dec 23, 2009 at 7:02 AM, Ricardo Mayerhofer
<ricardo.ekm.lis...@gmail.com> wrote:
> 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.
CheckGroup and RadioGroup are essentially the same thing as far as the
way they work. once you redesign CheckGroup the RadioGroup update will
be minimal.
i dont think there is a big problem requiring every component to have
an html tag. after all wicket is a component based framework where
components represent ui which is in turn represented by html tags. the
tags also carry with them importance on nesting, so i also dont think
its a problem that wicket components carry the same importance.
come up with a list of usecases where this is inconvenient and if
there are a lot we can address them. but i cant really see many past
Check/RadioGroup components.
>>> 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.
this has nothing to do with the difference in server-side processing,
this is more a design choice that promotes good reuse. lets say you
create a compound component that has two select boxes. if you do not
make it into a panel that means everywhere you use it you *have* to
know what kind of markup to put in, what the wicket:id values are for
the two select boxes that it uses, etc. in the future if you modify
this component to have a container around the two select boxes you now
have to find every place in your project where you used this component
and add the container. sounds like pita to me.
> 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.
agreed. we already do this with links and buttons. my guess is that it
has never bothered anyone enough to create an rfe.
>>> 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.
render order has to be defined somewhere. it can either be defined in
the markup or it can be defined in your code. if it is defined in your
code by the sequence of add() calls then every time the designer wants
to move anything around (even sibling components) you will have to
change the code. with the render order coming from markup this
restriction is only when the nesting of components changes. which one
seems more restrictive to you?
it is nice to have a cop-out of "this is not a business concern", but
that doesnt really mean anything when discussing this does it? when
working on any application you are always restricted by the technology
you are using whether it be your web framework, your application
server, your database, your operation system, your server, your
backbone, etc..
>>> 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.
and how would you define this "functional" relationship. it is very
convenient to be able to control certain things such as visiblity and
enabled state on a parent in order to be able to easily propagate it
to children.
we are always ears for new good ideas, but it takes more then "it
should work like this".
>>> - 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.
so now to get almost any bug fix you have to recompile, change code,
and redeploy the entire application. that seems like a highly risky
proposition. it basically means you can never really retire an
application that is feature-complete and simply drop new wars in to
get bug fixes, you always have to have active development on it. i
dont think many people will buy this approach.
> I think spring is a good example in this area. It has a pretty good backward
> compatibily, and use very few finals.
you are comparing apples to oranges. you do not write your application
"in" spring. spring is all about staying out of your code, so of
course they can do whatever the hell they want because they have very
few public apis. wicket, on the other hand, is opposite. in wicket
most apis *are* public and you use them in your code. we do not
provide interfaces for the same reason we use final methods, we do not
want to lock ourselves into a contract.
another point is that neither one of us has any visibility into the
internal development of spring. you are making this observation seeing
only the final product, but do you know how many times a core spring
developer thought to himself: damn, if only this method was final i
could throw in this new cool feature into the next minor release, or
better yet, damn if only this method was final i could fix this bug in
the next minor release instead of the next major one.
> 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.
so its ok if the next minor jdk update changes the api of String?
thats a concrete class...
>>> 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.
yes, it would be great to have an easy button. unfortunately every
application out there is different and there is no way we can provide
a set of defaults that will work for everyone out there.
we strive to hit the point at which "easy things are easy and hard
things are possible".
>>>
>>> Is there any hope for
>>> constructor change?
>>>
>>
>> what constructor change is that?
>>
>>
>
> From the discontinued 2.0.
there was a reason why 2.0 was discontinued. the constructor change
made some things that were easy before hard, and some things that were
possible before not possible anymore. the constructor change also did
not solve any of the issues that we have discussed here so i dont even
see how it is relevant.
-igor
>>
>> -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
