So you just want to throw all the components of a page or panel (the one
with markup) in 1 big place.
then all those have to be uniquely named ofcourse. Throughout the complete
page.
Repeaters will then be a bit special i guess. Because they are generation
ListItem components for you
that then also should be added to the page i guess (and made unique per
repeater) And they point again to some of the global pool components?
I think this will cost performance (if we still use linear lists) or memory
(if we are going to use hashmaps).
But after that if we all have this.. Wont the code be unreadable?
What is in where? Because i guess you then want to just add alll the
components you have on a page in the page constructor..
So that one will be quite large with no relations to each other.. Or are you
going to group them again? But then you are doing exactly the thing you do
now....
johan
P.S. i am against having 1 text field component.. TextArea and TexField are
also in html completely different beasts. I know there are ui (swt) that do
use 1, but others (swing) dont i like that separation..
On Wed, Dec 23, 2009 at 20:15, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> > 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 <
> igor.vaynb...@gmail.com>wrote:
> >>>
> >>>> 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<e-mail%3ausers-unsubscr...@wicket.apache.org>
> <e-mail%3ausers-unsubscr...@wicket.apache.org<e-mail%253ausers-unsubscr...@wicket.apache.org>
> >
> >>>> >>>> For additional commands,
> >>>> >>>> e-mail:users-h...@wicket.apache.org<e-mail%3ausers-h...@wicket.apache.org>
> <e-mail%3ausers-h...@wicket.apache.org<e-mail%253ausers-h...@wicket.apache.org>
> >
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>
> >>>> >>>
> ---------------------------------------------------------------------
> >>>> >>> To unsubscribe,
> >>>> >>> e-mail:users-unsubscr...@wicket.apache.org<e-mail%3ausers-unsubscr...@wicket.apache.org>
> <e-mail%3ausers-unsubscr...@wicket.apache.org<e-mail%253ausers-unsubscr...@wicket.apache.org>
> >
> >>>> >>> For additional commands,
> >>>> >>> e-mail:users-h...@wicket.apache.org<e-mail%3ausers-h...@wicket.apache.org>
> <e-mail%3ausers-h...@wicket.apache.org<e-mail%253ausers-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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
