you have the sources, you can build whatever infrastructure you need that is missing. lets see it.
-igor On Wed, Dec 23, 2009 at 11:15 AM, Martin Makundi <[email protected]> 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 >>>> <[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]> >>>>> >>>> For additional commands, >>>>> >>>> e-mail:[email protected]<e-mail%[email protected]> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>> >>>>> >>> --------------------------------------------------------------------- >>>>> >>> To unsubscribe, >>>>> >>> e-mail:[email protected]<e-mail%[email protected]> >>>>> >>> For additional commands, >>>>> >>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
