Igor, I'm sorry I've sounded unappreciative to the work the team is doing. Yes, I'm a dumb curmudgeon who is having a lot of problems adjusting to a new approach to things, and who, despite an honest effort to embrace the wicket outlook, may have stumbled, and also dove right in to the code base we started here with not enough in-depth reading of "Pro Wicket" and fiddling around with more toy examples.... and then after that, started to get childishly frustrated when things didn't go the way I expected. On slashdot I'm more inclined to state my biases in an extreme way, in part to get some counterargument -- and there actually ended up being some good counterargument there, some wicket fans who expressed how much they dig the approach. My team has decided on wicket as the extensible, page centric approach to the fairly complex app we have to write, and so far I've done a poor job of thinking about Wicket deeply enough to know the best approaches to things.
It's why I came here with a question like what would be the better way of doing this. Having had fragments pointed out to me (I knew more about panels, I think... at least to the extent of using them to wrap other components), and possibly thinking in terms of repeaters even though it's only going to be 2 or 3 things, I'll try to find some time and go back over some tutorials. On 8/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > I just dont understand how you expect us to continue helping you if you go > and talk trash about something we invest a lot of time in. Based on the > slashdot comments you left I dont really understand why you are using wicket > at all. > > -igor > > > On 8/29/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > Igor, sorry if I've irritated you. I know some of my frustration comes > > from A. an ugly reluctance to embrace change and B. Wicket is doing > > great things but it's somewhat early days, and the documentation > > (tutorial books and recipe collections) is still scanty. > > > > Eelco, thanks, your summary was accurate. I thought about a repeater, > > it seemed like overkill, and I thought maybe there was a "third > > way". (I still have to look into how the encompassing page would feed > > the links into the component, maybe not that difficult) > > > > So am I correct in thinking that, in general, most HTML pages in > > WIcket will have all possible subcomponents listed, and the visibility > > will control things that shouldn't be there... > > > > On 8/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > or just write something in perl and call it a day. > > > > > > -igor > > > > > > > > > On 8/29/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > So let me try to rephrase your problem: you have a header component > > > > that shows a variable number of components (links). Use a repeater > > > > (e.g. list view or repeating view) for the variable number of > > > > components, and you probably want to wrap the header component in a > > > > panel so that it is easy to move it around, place it on other pages, > > > > etc. Think a bit about whether those links should be internal or to > > > > bookmarkable pages, and that should do the trick, right? > > > > > > > > Eelco > > > > > > > > On 8/29/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > > Hey there-- > > > > > So I came up with a solution to this, but I suspect it's not very > > > > > Wicket-y, so I'd like some suggestions on best practices: > > > > > > > > > > We want a header component that can go on different pages, with 1 2 > > or > > > > > 3 links to other pages. > > > > > (Well, I guess ideally any #, but with my approach it was easier to > > > > > match it to the maximum shown in the spec). Visually, the end result > > > > > would be > > > > > > > > > > Back to: _LINK1_, _LINK2_ or _LINK3_ > > > > > > > > > > As far as i can tell, the links and their labels should be created > > by > > > > > the page containing the component. The trouble is, since the HTML > > and > > > > > wicket:id for displaying each link is in the HTML for the component, > > > > > the page has to "know" what ID to assign its link (and it doesn't > > > > > seem like you can change the id of a component object after its > > > > > created, which would have meant the page could just hand a list of > > > > > un-ID'd labeled links in, and the component could have re-IDed them > > to > > > > > match the HTML) > > > > > > > > > > So the component has a static callback getIdPrefixForLink() and > > > > > getIdPrefixForLinkLabel(), and the page uses that, and then uses > > that > > > > > string + 0, 1, or 2 for the links its making and handing to the > > > > > constructor of the Header component. > > > > > > > > > > So if the Component only gets 1 Labeled Link, it then creates > > > > > placeholder objects for the other 2, to make sure the hierarchy as > > > > > outlined in the HTML is still ok, and then just hides them. > > > > > > > > > > And there's a tad more logic for the commas and the "or". > > > > > > > > > > So, this all seems really hacky to me. What's a better way? In other > > > > > words: Is having to make place holders for everything that ever > > MIGHT > > > > > appear on a page or component, and then making them invisible when > > you > > > > > don't need them, the Wicket way, or is there something more direct? > > > > > And/or is there a standard way of letting parent pages or component > > > > > make subsubcomponents to be added to a subcomponent (e.g the Page > > > > > making PageLinks to be added to the Header component -- incidentally > > I > > > > > can't just pass in a reference to the class, because of what we had > > to > > > > > do to make "lazy loading" links that don't fully instantiate the > > page > > > > > they go to until that link is clicked.) > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
