Re: How to hide ListView rows the right way?
7zark7 i dont get your point. have you answered to the right thread? any other hints? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-hide-ListView-rows-the-right-way-tp3032125p3033271.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi, no offense meant, but the rhetoric in this thread is getting more and more ridiculous. Chicken? Component hierarchy hell? Seriously? At most maybe component hierarchy slight annoyance. I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements. The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write wicket:instantiate class=foo/? It's just another hierarchy element, isn't it? I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change. So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain! Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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
Re: Free wicket from component hierarchy hell
I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. Would you be happy if there was an application level configuration switch: getMarkupSettings().setAllowComponentAutoHierarchy(true); Which is default false? This way you can make sure nobody in YOUR project messes things up? ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi! So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. heree I can only ask you: Have you ever seen friction with your own eyes? It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. It might not be for everyone, but please don't deprive the needy ones. ** Martin Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:20:12 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. Would you be happy if there was an application level configuration switch: getMarkupSettings().setAllowComponentAutoHierarchy(true); Possibly. I'd rather not have the unnecessary complexity of this feature at all though. I certainly wouldn't want to support it if I was a wicket developer :-) Which is default false? This way you can make sure nobody in YOUR project messes things up? I have new projects every now and then, and most of them are already underway when I get called in. Which is why I like toolkits that do not encourage sloppiness(*). Carl-Eric www.wicketbuch.de *) sloppiness != easy to write I'm all for static typing, since it saves me the work of checking the types. I'd like it to be more like Scala, which saves me the typing I have to do in Java, while still giving me the same guarantees. With your proposed config switch, you're basically giving up one of Wicket's guarantees, the one that the hierarchy is what it looks like in the code. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:23:27 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. heree I can only ask you: Have you ever seen friction with your own eyes? Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. And as a consultant (I know, I said the nasty word) that is a pretty big part of what I do. Please consider the needy ones that would have to deal with this and would have to support people who made the mistake of using it :-) It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. If you only write code and never read or need to fix it. It might not be for everyone, but please don't deprive the needy ones. Well that certainly applies the other way around too. It's not for everybody, so please don't introduce a new source of bugs into *this* toolkit. Also, unless I missed a message (which is possible), so far we seem to have a needy *one*, not *ones*. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi! Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. Ah.. so you are trying to solve your problem probably from the wrong end? If you have bad warriors give them plastic swords so they can hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies, Dream teams, ... Please consider the needy ones that would have to deal with this and would have to support people who made the mistake of using it :-) I don't think there is a substitute for coding skills/talent ;))) It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. If you only write code and never read or need to fix it. I understand if you are a consultant it gives you plenty of billable to code again and again. But my sweetspot is product development and I need to make flexibly reusable components and unfortunately requiring html hierarchy to match on different pages makes really messy code on java side if I try to implement free-from-iherarchy in a manual way (I must provide various different parent containers to a generic component so that it can land in the right place). Well that certainly applies the other way around too. It's not for everybody, so please don't introduce a new source of bugs into *this* toolkit. Also, unless I missed a message (which is possible), so far we seem to have a needy *one*, not *ones*. Still, I don't think there is a substitute for coding skills/talent ;))) ** Martin Carl-Eric www.wicketbuch.de - 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
Wicket ajax-enabled enclosures
Hi! Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ? What I mean is that when I have: wicket:enclosure child=optional-field tr tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr /wicket If I set it invisible via ajax I cannot set it visible again. Instead, is there a way to do something like: tr wicket:enclosure=child:optional-field tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr So that it would automatically handle visible/hidden setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden element via ajax? @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/ ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Configuration of AbstractCalendar
Thanks, I figured it out. I have one more question ... can i use wicket behaviour to retrieve selected date from calendar or i have to write some JS hacks to do it? On 11/06/2010 06:38 PM, Igor Vaynberg wrote: i think its whatever format the yui component expects. -igor On Fri, Nov 5, 2010 at 9:25 AM, Jan Ferkojulyl...@gmail.com wrote: Hi, Can anyone tell me what is format of map for AbstractCalendar.configureWidgetProperties(Map map) ? For example I want to set navigator property to true, but map.put(navigator, true) doesn't work. thanks for answer Jan - 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
wicket 1.4.12 first time page visit
we noticed first time visit to the page is slow compared to next visits, we are using wicket 1.4.12, is there anything I can do to improve performance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-12-first-time-page-visit-tp3034418p3034418.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
This is pretty much exactly what I'd do given such a requirement. If something is so different as to require a different internal hierarchy, it's no longer the same component. Make a new component and use standard OO techniques for code reuse, like Frank wrote here. This certainly is not worth the can of worms that's being opened right now. Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:46:54 -0600 Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 14:21:46 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Here we finally come to an actual argument about this: Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. Frank wrote in another message how to deal with this case. I agree with him and add: If your new panel is so different from the old panel that it requires a different internal hierarchy, it's no longer the same component. Use standard OO techniques to deal with it. Also, think about whether your component design (as in what parts form a component, and what parts don't) is correct. Seems to me that in such a case too many things have been thrown together that should not be together. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:01:28 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. Ah.. so you are trying to solve your problem probably from the wrong end? If you have bad warriors give them plastic swords so they can hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies, Dream teams, ... So a clear architecture is a plastic sword? And do whatever you want is better? Please consider the needy ones that would have to deal with this and would have to support people who made the mistake of using it :-) I don't think there is a substitute for coding skills/talent ;))) There isn't. That's not the point. So far your argument seems to be #1 I don't like this and #2 those who don't agree with you aren't good coders. It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. If you only write code and never read or need to fix it. I understand if you are a consultant it gives you plenty of billable to code again and again. WTF? Your argument #3 is that *I* want to screw my customers over? Seriously? But my sweetspot is product development and I need to make flexibly reusable components and unfortunately requiring html hierarchy to match on different pages makes really messy code on java side if I try to implement free-from-iherarchy in a manual way (I must provide various different parent containers to a generic component so that it can land in the right place). This just doesn't make sense. Put your stuff in a panel, then it's a self-contained component and insulated from the hierarchy of the page and other components. Then you can put that component wherever you want. Well that certainly applies the other way around too. It's not for everybody, so please don't introduce a new source of bugs into *this* toolkit. Also, unless I missed a message (which is possible), so far we seem to have a needy *one*, not *ones*. Still, I don't think there is a substitute for coding skills/talent ;))) And I still haven't yet seen a convincing example of this being a problem worth adding the complexity. Then again, in the end the Wicket devs need to decide on whether they want to support this or not. So far *my* definitely non-binding vote is -1 :) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplin vitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Free wicket from component hierarchy hell
Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
your proposal is to wicket, what auto-generating-java-servlet-code is to a JSP (~ what a tied-and-deciding-designer-code was to a programmer-code in the past) that is, simply going back to hell :) why don't you stay on JSP domain, instead, sir? Please have some patience, just watch and see what will come out of it. You can decide for yourself whether to use it or not. Wicket community can decide whether to keep the patch as wicket-stuff or wicket. ** Martin On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller matthias.kel...@ergon.chwrote: Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Free wicket from component hierarchy hell
Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Wicket JQuery drag and drop behaviors
Just to let everyone know, this is just a simple imeplementation, there are no events triggered on draggable and therefore no methods called, so if anyone needs it just implement it .. So all the NPE checks and that kinda stuff is still needed ! All I needed for my case was to get the dropped component and I needed it to be done with JQuery. Regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Training - London, Munich, Bangalore, Amsterdam, Brussels
Public Wicket courses for autumn/winter 2010 are scheduled as follows: London [1]: Jan8-9(Sat-Sun), Jan10-11(Mon-Tue), Feb5-6(Sat-Sun), Feb7-8(Mon-Tue) Munich [1][2]: Nov11-12(Thu-Fri), Q1 TBD Amsterdam [1][3]: Nov11-12(Thu-Fri), Q1/Q2 TBD Bangalore [1]: Q1/Q2 TBD Brussels [3] Q1/Q2 TBD Please contact us [4] for any on-site/special content/date requirements. Regards - Cemal jWeekend Training, Consulting, Development http://jWeekend.com [1] http://jweekend.com/dev/BookingPage [2] http://comsysto.com/ [3] http://www.jteam.nl/training/apache-wicket-training.html [4] http://jweekend.com/dev/ContactUs - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi! I don't think there is a substitute for coding skills/talent ;))) There isn't. That's not the point. So far your argument seems to be #1 I don't like this and #2 those who don't agree with you aren't good coders. Bad coding was your argument, not mine ;) I simply don't allow bad coders into the equation. So a clear architecture is a plastic sword? No, but if you don't facilitate certaint things it sort of takes the edge off the blade ... child play stuff. You must prefer linux over windows, eh? All those linked libraries ... This just doesn't make sense. Put your stuff in a panel, then it's a self-contained component and insulated from the hierarchy of the page and other components. Then you can put that component wherever you want. Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. And I still haven't yet seen a convincing example of this being a problem worth adding the complexity. In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:05:39 -0500 James Carman ja...@carmanconsulting.com wrote: I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new container component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically wrap your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. +0.5 If this can be done with a special-case container (HighlyDangerousLiquidHierarchyMarkupContainer ;-) ), I wouldn't really mind, as long as the impact on the rest of the framework is small. I do not think it's worth it to change the whole framework around this special case. Especially since things like enabling/disabling of components based on their parents in the hierarchy don't seem to have been addressed yet. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JQuery drag and drop behaviors
Can it automatically detect which draggable dropped on droppable landing spot?
**
Martin
2010/11/9 armandoxxx armando@dropchop.com:
Hey
Just needed this so I wrote a simple implementation of Drag and Drop for
JQuery javascript lib.
So if anyone needs it .. be my guest to comment (and/or diSS) on it
Put on your page, app or anywhere else cause you need this !!!
wicket:head
wicket:linklink rel=stylesheet type=text/css
href=css/jquery/smoothness/jquery-ui-1.8.2.custom.css //wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-1.4.3.min.js/script/wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-ui-1.8.2.custom.min.js/script/wicket:link
/wicket:head
DraggableBehavior.java
/**
*
*/
package org.dropchop.jop.dnd.behaviors.draggable;
import java.util.HashMap;
import java.util.Map;
import org.apache.wicket.Component;
import org.apache.wicket.behavior.AbstractAjaxBehavior;
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.util.template.PackagedTextTemplate;
import org.apache.wicket.util.template.TextTemplate;
import org.dropchop.jop.dnd.behaviors.droppable.DroppableBehavior;
/**
* @author armando armando[DoT]ota[At]dropchop[DoT]com
*
*/
public class DraggableBehavior extends AbstractAjaxBehavior {
private static final long serialVersionUID = -4879330165262306147L;
//JQuery options
private DragType dragType = DragType.ORIGINAL;
/**
* Drag type for jQuery helper.
* CLONE - clones panel and after panel is droped cloned panel
dissapears.
* ORIGINAL - moves the original panel through the page.
* @author armando armando@dropchop.com
*/
public enum DragType {
ORIGINAL(original), CLONE(clone);
private String type = null;
/**
* Private constructor.
* @param theType jquery constant string
*/
private DragType(final String theType) {
this.type = theType;
}
/**
* Gets JQuery drag type constant.
* @return string.
*/
public String getType() {
return this.type;
}
}
/**
* Sets drag type for draggable component
* @param theType
* @return reference to itself for chaining.
*/
public DraggableBehavior setDragType(final DragType theType) {
this.dragType = theType;
return this;
}
�...@override
public void renderHead(final IHeaderResponse theResponse) {
super.renderHead(theResponse);
theResponse.renderOnDomReadyJavascript(this.getJavaScriptCode(this.getComponent()));
}
�...@override
protected void onBind() {
getComponent().setOutputMarkupId(true);
//uncomment this if you need styles for draggable component!
//getComponent().add(CSSPackageResource.getHeaderContribution(DroppableBehavior.class,
css/styles.css));
}
/**
* Uses js file as a template and returns parsed output.
*
* @param theComponentId id of date time field component.
* @return javascript code string.
*
* Note: this might be a performance issue ... figure and test it
out!!!
*/
private String getJavaScriptCode(final Component theComponent) {
PackagedTextTemplate template = new
PackagedTextTemplate(getClass(),
js/DraggableBehavior.js, text/javascript);
MapString, Object params = new HashMapString, Object();
params.put(componentId, theComponent.getMarkupId());
params.put(helper, this.dragType.getType());
params.put(wicketPath, theComponent.getPageRelativePath());
TextTemplate interpolated = template.interpolate(params);
return interpolated.asString();
}
/* (non-Javadoc)
* @see org.apache.wicket.behavior.IBehaviorListener#onRequest()
*/
�...@override
public void onRequest() {}
}
DraggableBehavior.js servers as a template for javascript code
$(#${componentId}).draggable(
{
cursor : 'pointer',
helper : '${helper}'
}
);
$('#${componentId}').data('wicketPath', '${wicketPath}');
DroppableBehavior.java
package org.dropchop.jop.dnd.behaviors.droppable;
import java.util.HashMap;
import java.util.Map;
import org.apache.wicket.Component;
import org.apache.wicket.Request;
import org.apache.wicket.RequestCycle;
import
Re: Wicket JQuery drag and drop behaviors
/**
* Notification method that a drop happened on this component.
* @param theComponent reference to dropped component.
*/
protected void onDrop(final AjaxRequestTarget theTarget, final Component
theComponent) {
System.out.println(Dropped: +
theComponent.getClass().getName());
}
you get the draggable component that was dropped.
Regards
Armando
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033686.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
your proposal is to wicket, what auto-generating-java-servlet-code is to a JSP (~ what a tied-and-deciding-designer-code was to a programmer-code in the past) that is, simply going back to hell :) why don't you stay on JSP domain, instead, sir? On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller matthias.kel...@ergon.chwrote: Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =)
Re: Free wicket from component hierarchy hell
Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) smime.p7s Description: S/MIME Cryptographic Signature
Re: Free wicket from component hierarchy hell
For what it's worth, I agree with these sentiments. I am not jazzed about this whole auto hierarchy idea. I too like the predictability of Wicket and I don't mind staying within the confines of a strict hierarchy. I've kept quiet until now because I really don't have the time to jump into this debate whole-heartedly, but I wanted to at least let my voice be heard as one who opposes such an idea. On Tue, Nov 9, 2010 at 3:15 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: Hi, no offense meant, but the rhetoric in this thread is getting more and more ridiculous. Chicken? Component hierarchy hell? Seriously? At most maybe component hierarchy slight annoyance. I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements. The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write wicket:instantiate class=foo/? It's just another hierarchy element, isn't it? I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change. So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain! Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 7:49 AM, manuelbarzi manuelba...@gmail.com wrote: why don't you stay on JSP domain, instead, sir? Let's keep it civil here folks. Can we agree to disagree without being disagreeable? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...
On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can you see the matrix?
;)
If you have:
html
form wicket:id=form
input wicket:id=input .../
/form
/html
public class MyPage extends WebPage {
public MyPage () {
add(new Form(form));
add(new TextField(input, model)); // Wicket could
automatically handle parse hierarchy from markup
}
}
**
Martin
2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
1. I want freedom inside panels.
2. Doubly defined hierarhices are redundant. Server-side hierarchy can
be automatically deduced from markup hierarcy. Such tasks should be
done by COMPUTER. Not coder.
**
Martin
2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
I think if you find component hierarchies to be hell, you probably
aren't
using Wicket right. Break things down into small reusable chunks using
Panels and you will find everything gets much, much easier.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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
Wicket JQuery drag and drop behaviors
Hey
Just needed this so I wrote a simple implementation of Drag and Drop for
JQuery javascript lib.
So if anyone needs it .. be my guest to comment (and/or diSS) on it
Put on your page, app or anywhere else cause you need this !!!
wicket:head
wicket:linklink rel=stylesheet type=text/css
href=css/jquery/smoothness/jquery-ui-1.8.2.custom.css //wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-1.4.3.min.js/script/wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-ui-1.8.2.custom.min.js/script/wicket:link
/wicket:head
DraggableBehavior.java
/**
*
*/
package org.dropchop.jop.dnd.behaviors.draggable;
import java.util.HashMap;
import java.util.Map;
import org.apache.wicket.Component;
import org.apache.wicket.behavior.AbstractAjaxBehavior;
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.util.template.PackagedTextTemplate;
import org.apache.wicket.util.template.TextTemplate;
import org.dropchop.jop.dnd.behaviors.droppable.DroppableBehavior;
/**
* @author armando armando[DoT]ota[At]dropchop[DoT]com
*
*/
public class DraggableBehavior extends AbstractAjaxBehavior {
private static final long serialVersionUID = -4879330165262306147L;
//JQuery options
private DragType dragType = DragType.ORIGINAL;
/**
* Drag type for jQuery helper.
* CLONE - clones panel and after panel is droped cloned panel
dissapears.
* ORIGINAL - moves the original panel through the page.
* @author armando armando@dropchop.com
*/
public enum DragType {
ORIGINAL(original), CLONE(clone);
private String type = null;
/**
* Private constructor.
* @param theType jquery constant string
*/
private DragType(final String theType) {
this.type = theType;
}
/**
* Gets JQuery drag type constant.
* @return string.
*/
public String getType() {
return this.type;
}
}
/**
* Sets drag type for draggable component
* @param theType
* @return reference to itself for chaining.
*/
public DraggableBehavior setDragType(final DragType theType) {
this.dragType = theType;
return this;
}
@Override
public void renderHead(final IHeaderResponse theResponse) {
super.renderHead(theResponse);
theResponse.renderOnDomReadyJavascript(this.getJavaScriptCode(this.getComponent()));
}
@Override
protected void onBind() {
getComponent().setOutputMarkupId(true);
//uncomment this if you need styles for draggable component!
//getComponent().add(CSSPackageResource.getHeaderContribution(DroppableBehavior.class,
css/styles.css));
}
/**
* Uses js file as a template and returns parsed output.
*
* @param theComponentId id of date time field component.
* @return javascript code string.
*
* Note: this might be a performance issue ... figure and test it
out!!!
*/
private String getJavaScriptCode(final Component theComponent) {
PackagedTextTemplate template = new
PackagedTextTemplate(getClass(),
js/DraggableBehavior.js, text/javascript);
MapString, Object params = new HashMapString, Object();
params.put(componentId, theComponent.getMarkupId());
params.put(helper, this.dragType.getType());
params.put(wicketPath, theComponent.getPageRelativePath());
TextTemplate interpolated = template.interpolate(params);
return interpolated.asString();
}
/* (non-Javadoc)
* @see org.apache.wicket.behavior.IBehaviorListener#onRequest()
*/
@Override
public void onRequest() {}
}
DraggableBehavior.js servers as a template for javascript code
$(#${componentId}).draggable(
{
cursor : 'pointer',
helper : '${helper}'
}
);
$('#${componentId}').data('wicketPath', '${wicketPath}');
DroppableBehavior.java
package org.dropchop.jop.dnd.behaviors.droppable;
import java.util.HashMap;
import java.util.Map;
import org.apache.wicket.Component;
import org.apache.wicket.Request;
import org.apache.wicket.RequestCycle;
import
Re: Wicket JQuery drag and drop behaviors
Hey guys .. 10x for sharing .. Was looking for it .. but didn't find anything so I implemented it on my own;) Regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3034347.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JQuery drag and drop behaviors
Hi Armandoxxx, If you want, you have too an implementation for your case with wiQuery (see: http://wiquery-examples-1-1-x.appspot.com/?wicket:bookmarkablePage=:org.odlabs.wiquery.examples.droppable.DroppablePage). But your approach is very ligthweight !! Regards Julien On Tue, Nov 9, 2010 at 2:30 PM, armandoxxx armando@dropchop.com wrote: Just to let everyone know, this is just a simple imeplementation, there are no events triggered on draggable and therefore no methods called, so if anyone needs it just implement it .. So all the NPE checks and that kinda stuff is still needed ! All I needed for my case was to get the dropped component and I needed it to be done with JQuery. Regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Free wicket from component hierarchy hell
As an alternative, suppose that one's non-panel compound component contained a map from wicket-id's to components. The hierarchy could be encoded in a lisp-like string; the component's constructor could parse the string and create the component hierarchy to match. The hierarchy string could be a configuration property that the constructor looks up. When you want to use the component on an HTML page whose wicket-ids are embedded differently, set the configuration parameter to the desired hierarchy string. So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? -Original Message- From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Sent: Tuesday, November 09, 2010 9:12 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell On Tue, 9 Nov 2010 14:21:46 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Here we finally come to an actual argument about this: Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. Frank wrote in another message how to deal with this case. I agree with him and add: If your new panel is so different from the old panel that it requires a different internal hierarchy, it's no longer the same component. Use standard OO techniques to deal with it. Also, think about whether your component design (as in what parts form a component, and what parts don't) is correct. Seems to me that in such a case too many things have been thrown together that should not be together. Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. That sounds really slick a good example of what we are trying to avoid having to do. ** Martin /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? That's not how proggress is made... ** Martin -Original Message- Fro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I think we have to make a vote whether this feature has to be investigated further. There are over 90 mails in the thread and I have the feeling that only Martin Makundi likes the idea. On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 10:23 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: That's not how proggress is made... Well, it's at least a sane place to start. Figuring out how Wicket can be used as-is to solve your problem lets you know if it's really a problem or not. If this can be done in a non-intrusive way, then you can just do it yourself and provide it as a wicketstuff module. If enough folks use it and say man, I really wish the core framework worked like this, then perhaps we consider putting it into the core. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Free wicket from component hierarchy hell
Progress is made by people who have understanding, not by the ignorant. You're not in a position to make suggestions about extending Wicket if you don't yet understand how to use the powers it already has. -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 9:23 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? That's not how proggress is made... ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SV: Free wicket from component hierarchy hell
That's not how proggress is made... No, but there are dozens of web frameworks, why try to progress Wicket into something that works in a way there perhaps already is another framework does? What you propose sounds close to how Tapestry already works, for instance... - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
That's not how proggress is made... Well, it's at least a sane place to start. Figuring out how Wicket can be used as-is to solve your problem lets you know if it's really a problem or not. I've been dabbling with Wicket for 2,5 years now, and I have now finally come up with this request for the core wicketeers to show us the correct way to patch this particular issue. I am very thankful for the very proactive proposition by Igor, we are working on it. If this can be done in a non-intrusive way, then you can just do it yourself and provide it as a wicketstuff module. If enough folks use it and say man, I really wish the core framework worked like this, then perhaps we consider putting it into the core. Sounds completely fair to me. ** Martin - 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
Re: Free wicket from component hierarchy hell
Progress is made by people who have understanding, not by the ignorant. You're not in a position to make suggestions about extending Wicket if you don't yet understand how to use the powers it already has. I feel I understand its powers and limitations. Its powers have not shown to be a problem, but its limitations need some alleviation ;) ** Martin -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 9:23 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? That's not how proggress is made... ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 17:23:18 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? That's not how proggress is made... So far you are *still* the only one in favor of this whole idea. You have not really replied to any of proposed solutions except with [paraphrased] I don't want to do it that way or some silliness about child's play. At the same time, you have not responded to valid criticisms like the problems with enabledInHierarchy (at least I haven't seen any such response). I finally understand your problem now that it has been defined somewhat, but I do not think your suggestion is a good solution to it. There are other solutions with a much smaller impact. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Well.. that's what we are doing, at runtime.
**
Martin
2010/11/9 manuelbarzi manuelba...@gmail.com:
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...
On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can you see the matrix?
;)
If you have:
html
form wicket:id=form
input wicket:id=input .../
/form
/html
public class MyPage extends WebPage {
public MyPage () {
add(new Form(form));
add(new TextField(input, model)); // Wicket could
automatically handle parse hierarchy from markup
}
}
**
Martin
2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
1. I want freedom inside panels.
2. Doubly defined hierarhices are redundant. Server-side hierarchy can
be automatically deduced from markup hierarcy. Such tasks should be
done by COMPUTER. Not coder.
**
Martin
2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
I think if you find component hierarchies to be hell, you probably
aren't
using Wicket right. Break things down into small reusable chunks using
Panels and you will find everything gets much, much easier.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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
Re: Free wicket from component hierarchy hell
I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new container component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically wrap your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote: I think we have to make a vote whether this feature has to be investigated further. There are over 90 mails in the thread and I have the feeling that only Martin Makundi likes the idea. On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Wicket JQuery drag and drop behaviors
Armando, Thanks for sharing. Did you know about [1] and [2]? Regards, Ernesto 1-http://code.google.com/p/wiquery/source/browse/trunk/src/main/java/org/odlabs/wiquery/ui/draggable/DraggableAjaxBehavior.java 2-http://code.google.com/p/wiquery/source/browse/trunk/src/main/java/org/odlabs/wiquery/ui/droppable/DroppableAjaxBehavior.java On Tue, Nov 9, 2010 at 2:30 PM, armandoxxx armando@dropchop.com wrote: Just to let everyone know, this is just a simple imeplementation, there are no events triggered on draggable and therefore no methods called, so if anyone needs it just implement it .. So all the NPE checks and that kinda stuff is still needed ! All I needed for my case was to get the dropped component and I needed it to be done with JQuery. Regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html Sent from the Users forum mailing list archive at Nabble.com. - 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
RE: Free wicket from component hierarchy hell
Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? IMO, No. -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Tuesday, November 09, 2010 9:06 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new container component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically wrap your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote: I think we have to make a vote whether this feature has to be investigated further. There are over 90 mails in the thread and I have the feeling that only Martin Makundi likes the idea. On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 10:32 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I've been dabbling with Wicket for 2,5 years now, and I have now finally come up with this request for the core wicketeers to show us the correct way to patch this particular issue. I'm not necessarily saying it's not an issue. I get what you're saying about having to stick to the hierarchy when designing markup files. I just don't know whether this approach is the best or not. Again, I really haven't had a chance to sit down and think it through. Sounds completely fair to me. Why don't you put this work into wicketstuff (or flesh it out more with Igor in his git repo first and then move it), so we can see what it's all about and perhaps try it out for ourselves? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 1.4.12 first time page visit
From which version did you upgrade ? I guess 1.4.8 (extracted from your recent mails about wicketstuff-push). You can start any Java profiler (JProfiler, YourKit, ...) and see what is slow. On Tue, Nov 9, 2010 at 4:08 PM, fachhoch fachh...@gmail.com wrote: we noticed first time visit to the page is slow compared to next visits, we are using wicket 1.4.12, is there anything I can do to improve performance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-12-first-time-page-visit-tp3034418p3034418.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JQuery drag and drop behaviors
Nice.
**
Martin
2010/11/9 armandoxxx armando@dropchop.com:
/**
* Notification method that a drop happened on this component.
* @param theComponent reference to dropped component.
*/
protected void onDrop(final AjaxRequestTarget theTarget, final
Component
theComponent) {
System.out.println(Dropped: +
theComponent.getClass().getName());
}
you get the draggable component that was dropped.
Regards
Armando
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033686.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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
Re: Wicket ajax-enabled enclosures
Hi! Has this been attempted before? Would it be a good idea to go at it? Sure would help removing some boilerplate webmarkupcontainer code. Existing jira issue for this? ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Hi! Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ? What I mean is that when I have: wicket:enclosure child=optional-field tr tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr /wicket If I set it invisible via ajax I cannot set it visible again. Instead, is there a way to do something like: tr wicket:enclosure=child:optional-field tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr So that it would automatically handle visible/hidden setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden element via ajax? @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/ ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket ajax-enabled enclosures
On Tue, Nov 9, 2010 at 4:39 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Has this been attempted before? Would it be a good idea to go at it? Sure would help removing some boilerplate webmarkupcontainer code. Existing jira issue for this? At least I haven't seen one. ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Hi! Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ? What I mean is that when I have: wicket:enclosure child=optional-field tr tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr /wicket If I set it invisible via ajax I cannot set it visible again. Instead, is there a way to do something like: tr wicket:enclosure=child:optional-field tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr So that it would automatically handle visible/hidden setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden element via ajax? @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/ ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
At the same time, you have not responded to valid criticisms like the problems with enabledInHierarchy (at least I haven't seen any such response). @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. I'm not necessarily saying it's not an issue. I get what you're saying about having to stick to the hierarchy when designing markup files. I just don't know whether this approach is the best or not. Again, I really haven't had a chance to sit down and think it through. @James I think Igor thought it through very well.. also Sebastian, Rodolfo and Michal have had very proactive comments. I apologise that it takes some time to code it, but we'll be back with a freebie for everybody to try out for themselves ;) ** Martin - 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
Re: Wicket ajax-enabled enclosures
It is pretty similar syntax to wicket:message. any pointers how to implement it or if there would be some pitfalls? I understand transarent markup containers are somewhat tricky? ** Martin 2010/11/9 Martin Grigorov mgrigo...@apache.org: On Tue, Nov 9, 2010 at 4:39 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Has this been attempted before? Would it be a good idea to go at it? Sure would help removing some boilerplate webmarkupcontainer code. Existing jira issue for this? At least I haven't seen one. ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Hi! Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ? What I mean is that when I have: wicket:enclosure child=optional-field tr tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr /wicket If I set it invisible via ajax I cannot set it visible again. Instead, is there a way to do something like: tr wicket:enclosure=child:optional-field tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr So that it would automatically handle visible/hidden setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden element via ajax? @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/ ** Martin - 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
Re: Wicket ajax-enabled enclosures
It's the same pattern as the last suggestion you had: 1) Generate a patch with a Quickstart that demonstrates the proposed functionality 2) Attach it to a Jira issue First impressions matter a lot, so if you post the Jira without the code, it's going to get ignored, possibly even after you post the code, which would waste your time. Why not get yourself organized and present yourself professionally? You sound eager and capable, show people your best! Brian On Nov 9, 2010, at 10:39 AM, Martin Makundi wrote: Hi! Has this been attempted before? Would it be a good idea to go at it? Sure would help removing some boilerplate webmarkupcontainer code. Existing jira issue for this? ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Hi! Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ? What I mean is that when I have: wicket:enclosure child=optional-field tr tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr /wicket If I set it invisible via ajax I cannot set it visible again. Instead, is there a way to do something like: tr wicket:enclosure=child:optional-field tdoptional content/td tdinput type=text wicket:id=optional-field//td /tr So that it would automatically handle visible/hidden setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden element via ajax? @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/ ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com wrote: If the component hierarchy can be changed without changing behavior or semantics, then why are the components in a hierarchy to begin with? Why aren't all the components being moved around already siblings at the same level? Does Wicket require that the order of sibling Wicket components match the order at which simply HTML elements appear? You could do that, but I think Martin is trying to take it a step further allowing you to have an arbitrary hierarchy in your markup and just figure it out at runtime. Wicket doesn't care what order you add stuff to the page/component as long as they're all on the same level within the hierarchy. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
You could do that, but I think Martin is trying to take it a step further allowing you to have an arbitrary hierarchy in your markup and just figure it out at runtime. Wicket doesn't care what order you add stuff to the page/component as long as they're all on the same level within the hierarchy. Yes, and if they are at different levels in the hierarchy, Wicket can figure that out also, at runtime. ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 10:58 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Yes, and if they are at different levels in the hierarchy, Wicket can figure that out also, at runtime. What happens if a sub-component changes one of the ids of one of its components that it contains? Is that then going to break your page because it's going to grab that id from you? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Cannot get current page from AjaxPagingNavigator
Hi all,
For some reason I cannot get the current page number. This is the relevant
part of my code:
PageableListView dataList = new PageableListView(dataList, results, 10) {
protected void populateItem(ListItem item) {
..
}
}
AjaxPagingNavigator pagination = new
AjaxPagingNavigator(navigator, dataList);
add(pagination);
Label currentPage = new Label(currentPage,
pagination.getPageable().getCurrentPage() + );
currentPage.setOutputMarkupId(true);
add(currentPage);
currentPage always returns 0.
I have also tried PagingNavigator with similar results.
Can anyone tell me what I have missed?
Regards
Vishal
Re: Free wicket from component hierarchy hell
Hi! What happens if a sub-component changes one of the ids of one of its components that it contains? Is that then going to break your page because it's going to grab that id from you? Igor explained that # Components can be queued to any container, and can only be added to the hierarchy that stems from that container, thereby solving the security requirement https://github.com/ivaynberg/wicket/tree/component-queuing ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 17:46:13 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:51:49 -0500 James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com wrote: If the component hierarchy can be changed without changing behavior or semantics, then why are the components in a hierarchy to begin with? Why aren't all the components being moved around already siblings at the same level? Does Wicket require that the order of sibling Wicket components match the order at which simply HTML elements appear? You could do that, but I think Martin is trying to take it a step further allowing you to have an arbitrary hierarchy in your markup and just figure it out at runtime. Wicket doesn't care what order you add stuff to the page/component as long as they're all on the same level within the hierarchy. I think you misunderstood Frank's point. Why are the components in a hierarchy in the first place, if the hierarchy can be changed without changing behavior or semantics? They can simply be flat in the parent then. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
one of the nice things of wicket is that java-code (programmer) and html-code (designer) are quite independent. only watching a wicket-java-file does a programmer deduce the structure and behaviour of the corresponding view, both things, without fully depending on inspecting html for understanding it all, in most cases. so, would your proposal tie programmers to requiring to watch the html-code to understand structure instead of a self-contained java-code. that's what old-fashioned frameworks do... Quite the opposite in the general case. I cannot come up with an example case that would require to watch the html code, more than we must do already now. ** Martin On Tue, Nov 9, 2010 at 5:08 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Sorry for miscommunicating.. we are not removing hierarcy. We are trying to automatically nest the components according to the hierarchy defined in markup. ** Martin Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 18:04:44 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Igor explained that # Components can be queued to any container, and can only be added to the hierarchy that stems from that container, thereby solving the security requirement https://github.com/ivaynberg/wicket/tree/component-queuing Having read the readme there, this is starting to finally make some sense. This proposed solution might actually work without too much breakage. I still don't see the necessity for this change, but I'm willing to change my -1 to a -0.5. I'll go for a -0 if it can be shown that the impact of this on the rest of Wicket is minimal (i.e., it needs few code changes and doesn't break any assumptions in framework or user code, for example about when exactly the component tree is available). Carl-Eric www.wicketbuch.de PS: I think much of this controversy could have been streamlined by pointing to a concept-complete implementation or at least making a properly thought-out suggestion, instead of all the name-calling that went on. (Almost) No offense taken, just a suggestion for the future. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Say you have two forms on one panel (don't know if this is the best
example or not, but here goes). You want to move a field from one
panel to another. You'd have to do that in code with the traditional
approach. With the queued approach, you'd just queue all your
components to the parent container and it would auto-add them to the
correct subcomponent as it finds them in the markup.
With this, the order does matter, though. Suppose you had two
components you wanted to queue with the same id, completely different
components. If you reverse their order, then they're auto-added in a
different order.
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
If you have code like:
panel {
queue(a(a));
a.queue(a(a));
}
It is pretty evident what goes into where but not very good naming convention ;)
**
Martin
-
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
Updating model object on AjaxFallbackDefaultDataTable page change
I have a CheckGroup that contains an AjaxFallbackDefaultDataTable that has a column containing a Check. As long as I click my submit button while on the first page of the DataTable, the model object of the CheckGroup is updated as expected with the items I had checked. However, if I check some checkboxes and then go to page 2 of the DataTable, the CheckGroup's model object is not updated and I lose everything I checked on page 1. The DataTable class has an onPageChanged() event, but it appears that it is called after the page is actually changed. My other thought was to add an AjaxFormComponentUpdatingBehavior to the Check, but Check is not a FormComponent. Any thoughts? Thanks, Matt
Re: Configuration of AbstractCalendar
the value should be available in the formcomponent's model the datepicker is attached to. -igor On Tue, Nov 9, 2010 at 2:27 AM, Jan Ferko julyl...@gmail.com wrote: Thanks, I figured it out. I have one more question ... can i use wicket behaviour to retrieve selected date from calendar or i have to write some JS hacks to do it? On 11/06/2010 06:38 PM, Igor Vaynberg wrote: i think its whatever format the yui component expects. -igor On Fri, Nov 5, 2010 at 9:25 AM, Jan Ferkojulyl...@gmail.com wrote: Hi, Can anyone tell me what is format of map for AbstractCalendar.configureWidgetProperties(Map map) ? For example I want to set navigator property to true, but map.put(navigator, true) doesn't work. thanks for answer Jan - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Igor explained that # Components can be queued to any container, and can only be added to the hierarchy that stems from that container, thereby solving the security requirement https://github.com/ivaynberg/wicket/tree/component-queuing Sorry, I was thinking for some reason that the depth-first search through the current component's hierarchy would actually traverse into subcomponent's markup, but I don't think it will. It will stay within the current component's markup looking for the matching id. Could fragments screw this up, since their markup is actually contained within the markup of their parent container? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
What happens if a sub-component changes one of the ids of one of its components that it contains? Is that then going to break your page because it's going to grab that id from you? Also depends what you mean by a component. A panel sitting on a panel has its own markup so it won't grab anything. ** Martin Igor explained that # Components can be queued to any container, and can only be added to the hierarchy that stems from that container, thereby solving the security requirement https://github.com/ivaynberg/wicket/tree/component-queuing ** Martin - 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
Re: Cannot get current page from AjaxPagingNavigator
You are using an static model, which only knows about the value by the time
of construction. Use a dynamic model
i.e: (make sure you define pagination as final)
Label currentPage = new Label(currentPage, new LoadableDetachableModel(){
public Object load(){
return pagination.getPageable().getCurrentPage();
}
});
On Tue, Nov 9, 2010 at 1:04 PM, vp143 [via Apache Wicket]
ml-node+3034524-366758351-65...@n4.nabble.comml-node%2b3034524-366758351-65...@n4.nabble.com
wrote:
Hi all,
For some reason I cannot get the current page number. This is the relevant
part of my code:
PageableListView dataList = new PageableListView(dataList, results, 10) {
protected void populateItem(ListItem item) {
..
}
}
AjaxPagingNavigator pagination = new
AjaxPagingNavigator(navigator, dataList);
add(pagination);
Label currentPage = new Label(currentPage,
pagination.getPageable().getCurrentPage() + );
currentPage.setOutputMarkupId(true);
add(currentPage);
currentPage always returns 0.
I have also tried PagingNavigator with similar results.
Can anyone tell me what I have missed?
Regards
Vishal
--
View message @
http://apache-wicket.1842946.n4.nabble.com/Cannot-get-current-page-from-AjaxPagingNavigator-tp3034524p3034524.html
To start a new topic under Apache Wicket, email
ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com
To unsubscribe from Apache Wicket, click
herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=.
--
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Cannot-get-current-page-from-AjaxPagingNavigator-tp3034524p3034563.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: When fragments are added they materialize as natural markup at the junction point? I don't know the answer to that. I'm asking, myself. :) Just trying to make sure the queue approach doesn't break with these typical use cases. I use fragments a lot! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: I think you misunderstood Frank's point. Why are the components in a hierarchy in the first place, if the hierarchy can be changed without changing behavior or semantics? They can simply be flat in the parent then. Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the queued approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
https://github.com/ivaynberg/wicket/tree/component-queuing Sorry, I was thinking for some reason that the depth-first search through the current component's hierarchy would actually traverse into subcomponent's markup, but I don't think it will. It will stay within the current component's markup looking for the matching id. Could fragments screw this up, since their markup is actually contained within the markup of their parent container? When fragments are added they materialize as natural markup at the junction point? ** Martin - 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
Re: Free wicket from component hierarchy hell
Martin, isn't it all a matter of principles towards keeping a correct separation of concerns? one of the nice things of wicket is that java-code (programmer) and html-code (designer) are quite independent. only watching a wicket-java-file does a programmer deduce the structure and behaviour of the corresponding view, both things, without fully depending on inspecting html for understanding it all, in most cases. so, would your proposal tie programmers to requiring to watch the html-code to understand structure instead of a self-contained java-code. that's what old-fashioned frameworks do... On Tue, Nov 9, 2010 at 5:08 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Sorry for miscommunicating.. we are not removing hierarcy. We are trying to automatically nest the components according to the hierarchy defined in markup. ** Martin Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
@Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Sorry for miscommunicating.. we are not removing hierarcy. We are trying to automatically nest the components according to the hierarchy defined in markup. ** Martin Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
From my understanding the proposal works like this that you have a partially code controlled hierarchy of components when you need it for functional reasons (security, AJAX refresh, visibility, etc). You can define the parent of a component but technical you allow child components being nested at will in the HTML markup (below that code controlled parent). So if you do parent.add(component) you say that the component must be either added as a direct or indirect child to this parent = if you do parent.setVisible(false) all childs will still be invisible no matter how they are nested among themselves. So you give the HTML designer a bit more freedom in layouting components below a given code controlled parent. I think that would be a reasonable approach. On 09.11.2010 17:05, Carl-Eric Menzel wrote: On Tue, 9 Nov 2010 17:46:13 +0200 Martin Makundimartin.maku...@koodaripalvelut.com wrote: @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
If you have code like:
panel {
queue(a(a));
a.queue(a(a));
}
This could be a problem. Say you do have two forms on the same page.
One form edits a Person and the other edits a Department. Each of
which have a name field (with id name) which are queued/auto-added
so that the Department's name field is queued before the Person's name
field. To begin with, in the markup, the Department form comes before
the Person form. Now, what if the designer switches the order of
the markup and puts the Person form before the Department form? Then,
the wrong name field will be added to the wrong form. Am I
understanding this correctly?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:33:31 -0500 James Carman ja...@carmanconsulting.com wrote: Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the queued approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. Ouch. I think this has the potential to be a showstopper. This will be an endless source of hard-to-find bugs. I think there needs to be a unique-id requirement when you start using queue. Right now we require unique-ids on the same hierarchy level, i.e. direct descendants of the same component. With queue, we're basically extending necessity that to the whole subtree. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
so queue each formcomponet under the form they belong to. that way
they cannot be moved outside the form.
-igor
On Tue, Nov 9, 2010 at 8:46 AM, James Carman ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
If you have code like:
panel {
queue(a(a));
a.queue(a(a));
}
This could be a problem. Say you do have two forms on the same page.
One form edits a Person and the other edits a Department. Each of
which have a name field (with id name) which are queued/auto-added
so that the Department's name field is queued before the Person's name
field. To begin with, in the markup, the Department form comes before
the Person form. Now, what if the designer switches the order of
the markup and puts the Person form before the Department form? Then,
the wrong name field will be added to the wrong form. Am I
understanding this correctly?
-
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
Re: Free wicket from component hierarchy hell
PS: I think much of this controversy could have been streamlined by pointing to a concept-complete implementation or at least making a properly thought-out suggestion, instead of all the name-calling that went on. (Almost) No offense taken, just a suggestion for the future. My apologies. I am quite bad at communicating my wicked ideas. However, the well thought suggestions from the wicketeers were necessary to get the solution growing. The solution and also the concept was invented collaboratively during the thread. For that I am very thankful ;) ** Martin - 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
Re: Cannot get current page from AjaxPagingNavigator
Use an dinamic model, ex:
Label currentPage = new Label(currentPage, new
AbstractReadOnlyModelString() {
public String getObject() {
return pagination.getPageable().getCurrentPage();
}
});
On Tue, Nov 9, 2010 at 2:04 PM, Vishal Popat vishal.po...@cipriati.co.ukwrote:
Hi all,
For some reason I cannot get the current page number. This is the relevant
part of my code:
PageableListView dataList = new PageableListView(dataList, results, 10) {
protected void populateItem(ListItem item) {
..
}
}
AjaxPagingNavigator pagination = new
AjaxPagingNavigator(navigator, dataList);
add(pagination);
Label currentPage = new Label(currentPage,
pagination.getPageable().getCurrentPage() + );
currentPage.setOutputMarkupId(true);
add(currentPage);
currentPage always returns 0.
I have also tried PagingNavigator with similar results.
Can anyone tell me what I have missed?
Regards
Vishal
--
Pedro Henrique Oliveira dos Santos
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? Both forms edit one particular object (say a Person). They just edit different values on the same object. Again, I'm not sure this is the best example, but it's at least plausible. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 7:36 AM, John Owen jo...@globalscape.com wrote: Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? it will not be changing the paradigm. it is adding a new method for you to add components. use it if you want, dont use it if you dont. -igor IMO, No. -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Tuesday, November 09, 2010 9:06 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new container component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically wrap your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote: I think we have to make a vote whether this feature has to be investigated further. There are over 90 mails in the thread and I have the feeling that only Martin Makundi likes the idea. On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
RE: Free wicket from component hierarchy hell
I don't understand your example. You have two forms on one panel. You wish to move a field (of one of the forms?) to another panel. Doesn't that imply that you've taken the field out of the form? -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Tuesday, November 09, 2010 10:34 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: I think you misunderstood Frank's point. Why are the components in a hierarchy in the first place, if the hierarchy can be changed without changing behavior or semantics? They can simply be flat in the parent then. Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the queued approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: so queue each formcomponet under the form they belong to. that way they cannot be moved outside the form. That's what happens in code not markup. You could potentially change what gets edited by the form merely by moving fields around in the markup. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Tue, 9 Nov 2010 10:51:49 -0500 James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com wrote: If the component hierarchy can be changed without changing behavior or semantics, then why are the components in a hierarchy to begin with? Why aren't all the components being moved around already siblings at the same level? Does Wicket require that the order of sibling Wicket components match the order at which simply HTML elements appear? You could do that, but I think Martin is trying to take it a step further allowing you to have an arbitrary hierarchy in your markup and just figure it out at runtime. Wicket doesn't care what order you add stuff to the page/component as long as they're all on the same level within the hierarchy. I think you misunderstood Frank's point. Why are the components in a hierarchy in the first place, if the hierarchy can be changed without changing behavior or semantics? They can simply be flat in the parent then. sadly there are valid usecases for having the hierarchy purely for design purposes. an easy example is: tr wicket:id=repeatertdspan wicket:id=first/ span wicket:id=last//td/tr now the designer wants tds to have a css class based on some condition. you now have to add a webmarkupcontainer to represent the td and renest first and last labels into it. the container is there purely for the design aspect. with queuing you can queue first and last under the repeater item. when you need to add css to td you simply queue the webmarkupcontainer under the repeater item as well and wicket will properly nest the labels in it for you. another usecase is introducing an arbitrary webmarkupcontainer just to have a div to repaint via ajax. it is hard to do this when refactoring a complex page because you have to find all the components that now need to be re-nested into the new container. hopefully queuing can eliminate some of this noise and make it easier. -igor Carl-Eric www.wicketbuch.de - 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
Re: Free wicket from component hierarchy hell
That's what happens in code not markup. You could potentially change what gets edited by the form merely by moving fields around in the markup. With compoundpropertymodels yes if you don't restrict components inside a form this can happen. For good or for bad. For security reasons in general, you might want to use: formA.queue(formAstuff); formB.queue(formBstuff); ** Martin - 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
Re: Free wicket from component hierarchy hell
um. no. queued components cannot be moved out of their parent. so if you queued field1 under form1 and the designer moves the tag tied to field1 outside the tag tied to form1 you will get the same error you would get now. -igor On Tue, Nov 9, 2010 at 8:50 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: so queue each formcomponet under the form they belong to. that way they cannot be moved outside the form. That's what happens in code not markup. You could potentially change what gets edited by the form merely by moving fields around in the markup. - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: For security reasons in general, you might want to use: formA.queue(formAstuff); formB.queue(formBstuff); But then you're right back where you started. Why not just add and not queue? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: um. no. queued components cannot be moved out of their parent. so if you queued field1 under form1 and the designer moves the tag tied to field1 outside the tag tied to form1 you will get the same error you would get now. I'm not saying that. I'm saying that if you queue the fields into the parent of form1 and form2, then you are free to move them between the forms solely in the markup. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann frank.silberm...@fedex.com wrote: I don't understand your example. You have two forms on one panel. You wish to move a field (of one of the forms?) to another panel. Doesn't that imply that you've taken the field out of the form? Not to another panel. To the other form within the same panel. All fields are queued to the panel, not the forms. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
ive outlined a couple of usecases when this is useful in another email. see there. -igor On Tue, Nov 9, 2010 at 8:56 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: For security reasons in general, you might want to use: formA.queue(formAstuff); formB.queue(formBstuff); But then you're right back where you started. Why not just add and not queue? - 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
Re: Free wicket from component hierarchy hell
yes, and that would of course be a mistake. if you just queue everything into the page you can cause serious security problems. sometimes you have a hard container you want your components to live under, and other times you dont care. you should always queue into the hard container, just like you add to something under it now. -igor On Tue, Nov 9, 2010 at 8:57 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: um. no. queued components cannot be moved out of their parent. so if you queued field1 under form1 and the designer moves the tag tied to field1 outside the tag tied to form1 you will get the same error you would get now. I'm not saying that. I'm saying that if you queue the fields into the parent of form1 and form2, then you are free to move them between the forms solely in the markup. - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: For security reasons in general, you might want to use: formA.queue(formAstuff); formB.queue(formBstuff); But then you're right back where you started. Why not just add and not queue? http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: yes, and that would of course be a mistake. if you just queue everything into the page you can cause serious security problems. sometimes you have a hard container you want your components to live under, and other times you dont care. you should always queue into the hard container, just like you add to something under it now. The point is that this new approach can allow the designer to move things around, potentially changing the semantics of how things work. For example, a TextField may have validators set up on it that are applicable within the context of one type of form, but may be completely inappropriate in another form. I'm not saying I'm against the queue approach necessarily, but I want to point out how you can get some pretty weird stuff happening just by moving the markup around. Do we want to open up that can of worms? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
The point is that this new approach can allow the designer to move things around, potentially changing the semantics of how things work. For example, a TextField may have validators set up on it that are applicable within the context of one type of form, but may be completely inappropriate in another form. I'm not saying I'm against the queue approach necessarily, but I want to point out how you can get some pretty weird stuff happening just by moving the markup around. Do we want to open up that can of worms? (You) as a coder will be responsible for opening that can ;] For good and for bad. Not wicket. Nor members of this discussion. ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 Did you mean to try to make me print this post? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
martin.maku...@koodaripalvelut.com wrote: http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 Did you mean to try to make me print this post? Hehe... I did not find antoher way to point to a single post ;] ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: (You) as a coder will be responsible for opening that can ;] For good and for bad. Not wicket. Nor members of this discussion. How many times have you done this: add(new TextField(...)) when you meant to do: someSubComponent.add(new TextField(..)) With add, you'll get an exception if the ids/hierarchy don't match up. Now, what if you're queueing instead? Suppose the user does: queue(new TextField(...)) which will work perfectly fine, but they meant to do (to enforce security): someSubComponent.queue(new TextField(...)) Now, since security is not enforced the designer has the freedom to move stuff around and royally hose things up. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi! First of all, normally I have junit tests that validate the functionality for me for regression purposes. Suppose the user does: queue(new TextField(...)) which will work perfectly fine, but they meant to do (to enforce security): someSubComponent.queue(new TextField(...)) Now, since security is not enforced the designer has the freedom to move stuff around and royally hose things up. Yes, if you are unsure, you should use add() to make sure. You get that extra security with that extra effort, if you want. ** Martin - 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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Yes, if you are unsure, you should use add() to make sure. You get that extra security with that extra effort, if you want. Again, the point is (regardless of unit tests) that you can unknowingly do something that allows stuff to break later quite easily. I'm just playing devil's advocate here. Allowing a markup change to modify the functionality of the behind the scenes code is dangerous, IMHO. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
