what does that have to do with OO exactly?
hmm..
It should be sufficient that the artist thinks the gfx are immacculate
and that the java developer thinks the code is immacculate. Why do we
need to couple java with html hierarchies and stuff? Some namespace
attribute could suffice to allow nested components.
put your money where your mouth is, come up with a prototype.
Does wicket have a single point where it manages which component
becomes the child of another and where the markup is loaded from? If
yes, I could try to introduce a namespace attribute.
we synchronize with the markup and lose some OOP, but we gain in desing.
Have you ever change the look and feel of your application? with wicket
it
is really easy, in other frameworks it is a nightmare.
If you give up coupling between html and java you do not lose the ease
of design. Actually you will gain more ease and freedom of design.
Furthermore, coding will be much faster as in most (80-90%) cases you
need only a single namespace per panel and you could go about it
without the need to worry about how the components are nested in html
<> java.
When I build a new panel I believe a significant amount of time is
spent in synchronizing html and java. That's work time spent that is
not really adding value in linear amount.
**
Martin
-igor
**
Martin
On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg<
[email protected]>wrote:
and where is this more OO?
-igor
On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
<[email protected]> wrote:
I vote +1 for more OO Wicket. Way to go Ricardo!
**
Martin
2009/12/23 Ricardo Mayerhofer<[email protected]>:
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
<[email protected]> 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:[email protected]<e-mail%[email protected]>
<e-mail%[email protected]<e-mail%[email protected]>
For additional commands,
e-mail:[email protected]<e-mail%[email protected]>
<e-mail%[email protected]<e-mail%[email protected]>
---------------------------------------------------------------------
To unsubscribe,
e-mail:[email protected]<e-mail%[email protected]>
<e-mail%[email protected]<e-mail%[email protected]>
For additional commands,
e-mail:[email protected]<e-mail%[email protected]>
<e-mail%[email protected]<e-mail%[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
