Re: best practice for a header component with links defined by the page
On 9/1/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i have just about zero swing experience :) I think I have even less swing experience, I doubt my playground experience from 25 years ago counts... Martijn I can testify that Wicket actually improved my Swing skills a few times over :) Recently I had to go back to doing a couple of Swing screens and all those inner classes and model objects were a breeze...
Re: best practice for a header component with links defined by the page
Recently I had to go back to doing a couple of Swing screens and all those inner classes and model objects were a breeze... +1 I have done a lot of swing coding before and for the past 6 months in wicket. I can definitely say this- Although wicket has a lot of swing like programming style in it, wicket is SO MUCH more easier to work with .It just hit me yesterday when i was again writing a couple of swing classes... Wicket has def improved the way I write Object oriented code. -swaroop
Re: best practice for a header component with links defined by the page
On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote:
I will not argue against Lisp. The paucity of Lisp/Scheme/Haskell
within professional software development is criminal. That is why,
for example, we will be seeing continuations in Java 7.
Heh, even though the idea goes so far, that reminds me of the hint of
Lisp that lives in Perl's list/array syntax, i.e. $foo =
(bar,baz);
That then reminds me of an odd syntax asymmetry in mostly all (I think
Algol-derived, though I may be getting that wrong, in practice I
tend to think of it as C-derived) languages: functions take multiple
arguments but return a single value... sometimes I wish I could do
something like Perl's
($foo,$bar,$baz) = func();
sub func{
return (1,2,3);
}
in Java. Maybe though my reluctance to, say, write a class the solely
exists as a bundler / wrapper class for the multiple values I would
want to return ties into my lack of grace in turning to inner
classes... one-off classes feels a bit like needlessly multiplying
entities, and while as Igor points out reusable-ness is at best a
happy by-product of good OO, it's so often touted and taught as a
benefit that I have trouble shaking that feeling.
I confess, with the academic Lisp I've had, I have a hard time
grasping how you would do many simple tasks within the paradigm (and
not shoehorning the mentality of other languages into the syntax.) I'm
always worried I'll end up with something like my brief academic stint
with Prolog, the assigment was, given basic parent/child relationship
definitions, construct rules for determining grandparent/aunt/uncles
etc. The core of it was easy enough, but the best the professor (whom
I admire greatly) could come up with to weed out duplicates was an
ungainly, procedural-looking hack.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
Wicket is not for newbie OOP developers. We don't pretend that it is. That was never the goal. You need rather solid OO skills to get Wicket. But if you want to learn, I think Wicket is a pretty good material. I'm going to go out on a limb - because I'm sure there are plenty of anecdotal exceptions, and maybe it'll sound too defensive anyway - that it's not just pure OO skills that come in useful to bring to the Wicket party, but expereince with OO UI Skills, and specifically Swing. An interesting concept in thinking about Model 2+, homegrown approaches is how Ajax and DHTM change things. One option new browser technologies are allowing is MUCH of the work to be moved to the client, with HTTP only being used when storing things on the server or at least in the session. So your scenario of multifaceted, stateful things would really need a good ponder for me to consider how I'd do that in HTTP-centric approaches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
Good luck with such solutions. If you want to build things like that, you've got basically two approaches. Use GWT (or something alike) - code logic in limited subset of java and have it magically translated to javascript. This seems somewhat fragile and limiting to me, but I don't have enough experience with it to judge. Other approach is to build the thing using raw javascript. Now I've done quite a lot of javascript work, and i can tell you that it's not the most productive way. Java (as any strongly typed) language has tremendous maintainability and refactoring advantage. Compared to that, javascript with all it's quirks, browser specific implementation (hell, it's not even called JavaScript in IE) and a cumbersome object model (no, i don't think prototyping is that cool), weak static checking and no refactoring support doesn't seem to be the right development platform to me. -Matej On 9/1/07, Kirk Israel [EMAIL PROTECTED] wrote: Wicket is not for newbie OOP developers. We don't pretend that it is. That was never the goal. You need rather solid OO skills to get Wicket. But if you want to learn, I think Wicket is a pretty good material. I'm going to go out on a limb - because I'm sure there are plenty of anecdotal exceptions, and maybe it'll sound too defensive anyway - that it's not just pure OO skills that come in useful to bring to the Wicket party, but expereince with OO UI Skills, and specifically Swing. An interesting concept in thinking about Model 2+, homegrown approaches is how Ajax and DHTM change things. One option new browser technologies are allowing is MUCH of the work to be moved to the client, with HTTP only being used when storing things on the server or at least in the session. So your scenario of multifaceted, stateful things would really need a good ponder for me to consider how I'd do that in HTTP-centric approaches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
they are not fancier then generic data structures. they exist for a reason
and can do things other generic data structures cannot. i suggest you read
up on them, they are a pretty standard part of oop and are used throughout
java - unless of course you have been living in a struts-like land where oop
is replaced with procedural programming and you only use a small subset of
java.
-igor
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote:
Well, that's a good point--
They aren't complex, per se, but they (and especially anonymous inner
classes) seem to show up a lot more in the class of programming of
which Applets and Wicket are both subsets than they do in most of the
rest of Java land. So they're a little less familiar to me, and I'm
not sure if they represent more complexity (given they're obviously
fancier than using more generic data structures in that they may be
doing arbitrarily complex things in their functions) or less (since
they live in the same .java file as the page, and can be nicely tuned
to handle the problem at hand).
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
heh, if you think inner classes are complex you are def using the wrong
framework
-igor
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still calling
into static functions to know what id to give the caption and label.
Plus I had to create an additional class to hold that link plus the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's less
kludgey than what i had earlier.
Thanks.
-
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]
Re: best practice for a header component with links defined by the page
That is why flat, page/request granularity web UI frameworks have
succeeded. They are simple and procedural. The reason that languages
such as Smalltalk, Java C# are much better than languages such as
Fortan, Pascal and C is that the former have a range of syntax,
objects, that their procedural predecessors lack.
In an OO language one can wrap data and behavior up into objects and
then assemble those objects and pass them to other objects.
From my perspective that is the value that Wicket brings to web
development. Now a developer has the power of OO instead of being
stuck writing the same sort of procedural code that would be at home
in Cobol.
The bright side to all of this is that a Java developer that gets OO
is worth 3 or 4 that don't. I review most of the interviews that come
in to Vegas.com and I conduct most of the phone screen interviews. I
don't consider anyone who doesn't get objects. That is our base line
for entry. So put in the work. It's worth it.
Oh, and does anyone want to move to sunny Las Vegas and work with a
team of a dozen other developers who get it? We're still hiring --
especially folk with experience with Wicket.
Cheers,
Scott
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote:
Well, that's a good point--
They aren't complex, per se, but they (and especially anonymous inner
classes) seem to show up a lot more in the class of programming of
which Applets and Wicket are both subsets than they do in most of the
rest of Java land. So they're a little less familiar to me, and I'm
not sure if they represent more complexity (given they're obviously
fancier than using more generic data structures in that they may be
doing arbitrarily complex things in their functions) or less (since
they live in the same .java file as the page, and can be nicely tuned
to handle the problem at hand).
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
heh, if you think inner classes are complex you are def using the wrong
framework
-igor
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still calling
into static functions to know what id to give the caption and label.
Plus I had to create an additional class to hold that link plus the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's less
kludgey than what i had earlier.
Thanks.
-
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]
--
Scott Swank
reformed mathematician
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote:
Probably the most difficult grinding of gears, then, for someone who
gets the syntax and knows the basic concept in theory more than
practice, is the idea that it's reasonable to make small, single uses
class definitions (as opposed to setting properties on instances of
classes) for the task at hand and not worry that they can't or won't
be used elsewhere, just in the local file. On a surface level at
least, this goes against the grain of objects as reusable components
that should be first class objects (though obviously the trick can be
to make the appropriate first class objects that can then be
customized locally)
that is wrong, the defininition of the object is not that it is reusable -
it is that it encapsulates data and functions that act upon that data. the
fact that this leads to good reusability is a side effect imho.
so taking anonymous classes - no they are not reusable - but they are used
to modify the behavior of whatever it is they subclass.
inner classes are, in fact, reusable, but with a much smaller scope. they
are reusable within the top level class. this is why not all classes, even
top level, are public.
-igor
On 8/31/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
they are not fancier then generic data structures. they exist for a
reason
and can do things other generic data structures cannot. i suggest you
read
up on them, they are a pretty standard part of oop and are used
throughout
java - unless of course you have been living in a struts-like land where
oop
is replaced with procedural programming and you only use a small subset
of
java.
-igor
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote:
Well, that's a good point--
They aren't complex, per se, but they (and especially anonymous inner
classes) seem to show up a lot more in the class of programming of
which Applets and Wicket are both subsets than they do in most of the
rest of Java land. So they're a little less familiar to me, and I'm
not sure if they represent more complexity (given they're obviously
fancier than using more generic data structures in that they may be
doing arbitrarily complex things in their functions) or less (since
they live in the same .java file as the page, and can be nicely tuned
to handle the problem at hand).
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
heh, if you think inner classes are complex you are def using the
wrong
framework
-igor
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for
generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still
calling
into static functions to know what id to give the caption and
label.
Plus I had to create an additional class to hold that link plus
the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's
less
kludgey than what i had earlier.
Thanks.
-
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]
Re: best practice for a header component with links defined by the page
On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote: That is why flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. The reason that languages such as Smalltalk, Java C# are much better than languages such as Fortan, Pascal and C is that the former have a range of syntax, objects, that their procedural predecessors lack. I want to hear you argue with the people who feel Lisp (Paul Graham among them) is horribly under-represented in software development outside of Academia. (The trouble with Lisp (at least as it was taught in Princeton-program based Universities in the early 90s) is that, like a lot of languages, you tend to judge it on its common APIs and libraries, and for many students that's just a primitive little command loop with primitive file I/O at best.) And I swear, I'm trying to learn here, and not pick fights. I'm also trying to not let me sometimes working out of my comfort zone make me highly defensive or judgemental. So let me play devil's advocate here: You said flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. Simplicity is often regarded as a good thing. Probably, it is, in of itself, a good thing: the problem then occurs where you try to use the simple methods on problems they go beyond their scope. CGI-centric approaches offer some beautifully simple concepts, a pretty hammer that (I'd say) may well be right for many programming situations: a simple key/value map for input, another key/value map for storing things on a session, output as text that the browser will interpret and turn into screen elements. This may even map well to how civilians see the web. (as opposed to a desktop app). They click a link, they get a page. Click, page. Form, Click, page. But not every problem is a nail for this simple hammer. In practice, I'd say there are a few gotchas to be aware of w/ page-centric approaches. One is the general issue of conceptual weight. This is probably worse for shlubs like me, but even then, there tend to be more things to be kept track of, more potential interactions , and more things to know about -- especially because I feel, in practice, Wicket doesn't let you know THAT much less about the HTML, Javascript, and CSS,(There are exceptions, for the prebuilt component, but those aren't core Wicket.) but requires you to understand how to apply that knowledge in the Wicket context. The second gotcha for people, especially who are a bit procedural minded, is the stacktrace problem. The more OO- you are, the more what you are seeing on screen (whether a complete webpage or a stacktrace) is the result of properly established object and relations earlier in the app workflow, the tougher it can be to know where the mistake occurred. Sometimes it's not a problem, and the 2 lines you see of your code are around where the error was, and other times Wicket is pretty helpful in telling you the kind of thing that went wrong. So in short... I get objects and have for a while. But I'm learning that there are further levels of getness I can aspire to. In an OO language one can wrap data and behavior up into objects and then assemble those objects and pass them to other objects. From my perspective that is the value that Wicket brings to web development. Now a developer has the power of OO instead of being stuck writing the same sort of procedural code that would be at home in Cobol. The bright side to all of this is that a Java developer that gets OO is worth 3 or 4 that don't. I review most of the interviews that come in to Vegas.com and I conduct most of the phone screen interviews. I don't consider anyone who doesn't get objects. That is our base line for entry. So put in the work. It's worth it. Oh, and does anyone want to move to sunny Las Vegas and work with a team of a dozen other developers who get it? We're still hiring -- especially folk with experience with Wicket. Cheers, Scott On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote: Well, that's a good point-- They aren't complex, per se, but they (and especially anonymous inner classes) seem to show up a lot more in the class of programming of which Applets and Wicket are both subsets than they do in most of the rest of Java land. So they're a little less familiar to me, and I'm not sure if they represent more complexity (given they're obviously fancier than using more generic data structures in that they may be doing arbitrarily complex things in their functions) or less (since they live in the same .java file as the page, and can be nicely tuned to handle the problem at hand). On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote: heh, if you think inner classes are complex you are def using the wrong framework -igor On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote: Ok, thanks... I refactored what i had with this in mind. It was a little more
Re: best practice for a header component with links defined by the page
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote: On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote: That is why flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. The reason that languages such as Smalltalk, Java C# are much better than languages such as Fortan, Pascal and C is that the former have a range of syntax, objects, that their procedural predecessors lack. I want to hear you argue with the people who feel Lisp (Paul Graham among them) is horribly under-represented in software development outside of Academia. (The trouble with Lisp (at least as it was taught in Princeton-program based Universities in the early 90s) is that, like a lot of languages, you tend to judge it on its common APIs and libraries, and for many students that's just a primitive little command loop with primitive file I/O at best.) And I swear, I'm trying to learn here, and not pick fights. I'm also trying to not let me sometimes working out of my comfort zone make me highly defensive or judgemental. So let me play devil's advocate here: You said flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. Simplicity is often regarded as a good thing. Probably, it is, in of itself, a good thing: the problem then occurs where you try to use the simple methods on problems they go beyond their scope. CGI-centric approaches offer some beautifully simple concepts, a pretty hammer that (I'd say) may well be right for many programming situations: a simple key/value map for input, another key/value map for storing things on a session, output as text that the browser will interpret and turn into screen elements. This may even map well to how civilians see the web. (as opposed to a desktop app). They click a link, they get a page. Click, page. Form, Click, page. But if you have application this simple, then using Wicket is like killing a fly with a racket launcher. But not every problem is a nail for this simple hammer. In practice, I'd say there are a few gotchas to be aware of w/ page-centric approaches. One is the general issue of conceptual weight. This is probably worse for shlubs like me, but even then, there tend to be more things to be kept track of, more potential interactions , and more things to know about -- especially because I feel, in practice, Wicket doesn't let you know THAT much less about the HTML, Javascript, and CSS,(There are exceptions, for the prebuilt component, but those aren't core Wicket.) but requires you to understand how to apply that knowledge in the Wicket context. Huh? You can write AJAX applications without writing a single line of javascript. And I know people who have next to nothing knowledge of Javascript and are developing AJAX application with Wicket. HTML? CSS? The point of Wicket is that it doesn't shield you from HTML or CSS. It doesn't even attempt to. If you don't want to know anything about HTML/CSS then Wicket definitely is wrong choices. But what Wicket shields you from is HTTP. You don't have to think in requests/responses. You don't have to construct URLs and to parse them. You don't have to maintain session attributes (how often do you cleanup session attributes in regular model 2 applications, if at all?). You don't have to process form submittions automatically (which button submitted the form? what should be selected checkbox value?). You probably haven't been burned enough by a manual state management (such as I can't add a tabbed panel into this page, because i'd have to change every single link to preserve the selected tab). Image a model 2 application with two sortable pageable lists, tree, tabbed panel and two forms. With Wicket it's dead simple. Try that with struts. The second gotcha for people, especially who are a bit procedural minded, is the stacktrace problem. The more OO- you are, the more what you are seeing on screen (whether a complete webpage or a stacktrace) is the result of properly established object and relations earlier in the app workflow, the tougher it can be to know where the mistake occurred. Sometimes it's not a problem, and the 2 lines you see of your code are around where the error was, and other times Wicket is pretty helpful in telling you the kind of thing that went wrong. So in short... I get objects and have for a while. But I'm learning that there are further levels of getness I can aspire to. Wicket is not for newbie OOP developers. We don't pretend that it is. That was never the goal. You need rather solid OO skills to get Wicket. But if you want to learn, I think Wicket is a pretty good material. -Matej In an OO language one can wrap data and behavior up into objects and then assemble those objects and pass them to other objects. From my perspective that is the value that Wicket brings to web development. Now a developer has the power of OO instead of being stuck writing the same
Re: best practice for a header component with links defined by the page
On 8/30/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. Irritated? You obviously lack basic Wicket knowledge even though you claim to be using it for months (Now, after months of using Wicket...). But happily, you don't let that fact hinder you from bitching about Wicket. This certainly isn't the right attitude if you come here for help. 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... Doesn't have to be. You should use panels or fragments for things like this. There is no reason for unused component placeholders. After months of using Wicket, this might be the right time to learn about panels and fragments... -Matej 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]
RE: best practice for a header component with links defined by the page
Igor, sorry if I've irritated you. I know some of my frustration comes from ... This certainly isn't the right attitude if you come here for help. Well... if it means anything, from my perspective, the more I use Wicket, the more I love it. I'm discovering new, and great things every day. :-) Thanks all for all the great work! :-D Cheers, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
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
Re: best practice for a header component with links defined by the page
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote: 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. Thanks Kirk. I think we've all had occasions where we put biased opinions in public where we maybe regretted it later. I know I've been there. To the upside: there's never a dull moment on this list. More drama than an average soap opera :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
interface menuitem extends serializable { imodel getlabel(); abstract void
onclick(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
populateitems(item item) {
menuitem mi=item.getmodelobject();
link link=new link(link, item.getmodel()) {
onclick() { ((menuitem)getmodelobject()).onclick(); }
}
item.add(link);
link.add(new label(label, mi.getlabel());
}
}
}
ulli wicket:id=menua wicket:id=linkspan
wicket:id=label/span/a/li/ul
-igor
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
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: best practice for a header component with links defined by the page
+1 here too. Although I am new to Wicket I realized very quickly why it is a great framework. I have developed webapps in Java for 6 years, and this is truly the first framework I've come across where there is no disconnect or learning curve for a Designer to create my screens for me. JSP promissed it, JSF kind-of supported it through Dreamweaver plugins, but Wicket is the win. Craig. On 8/30/07, Justin Morgan (Logic Sector) [EMAIL PROTECTED] wrote: Well... if it means anything, from my perspective, the more I use Wicket, the more I love it. I'm discovering new, and great things every day. :-) Thanks all for all the great work! :-D +1 I feel the same way. There are a lot of us out here on the Internet who really like Wicket, and we really appreciate all that Wicket's developers do for us. I just wanted to say many thanks from all of us. - Justin On Aug 30, 2007, at 6:02 AM, David Leangen wrote: Igor, sorry if I've irritated you. I know some of my frustration comes from ... This certainly isn't the right attitude if you come here for help. Well... if it means anything, from my perspective, the more I use Wicket, the more I love it. I'm discovering new, and great things every day. :-) Thanks all for all the great work! :-D Cheers, Dave - 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]
Re: best practice for a header component with links defined by the page
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
interface menuitem extends serializable { imodel getlabel(); abstract void
onclick(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
populateitems(item item) {
menuitem mi=item.getmodelobject();
link link=new link(link, item.getmodel()) {
onclick() { ((menuitem)getmodelobject()).onclick(); }
}
item.add(link);
link.add(new label(label, mi.getlabel());
}
}
}
Or use bookmarkable links instead of normal links if e.g. you are
building a menu bar that needs to be clickable even if the session
expires.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
right
interface menuitem extends serializable { imodel getlabel(); class? extends
page getpageclass(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
populateitems(item item) {
menuitem mi=item.getmodelobject();
link link=new bookmarkablepagelink(link, mi.getpageclass
());
item.add(link);
link.add(new label(label, mi.getlabel());
}
}
}
ulli wicket:id=menua wicket:id=linkspan
wicket:id=label/span/a/li/ul
On 8/30/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
interface menuitem extends serializable { imodel getlabel(); abstract
void
onclick(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
populateitems(item item) {
menuitem mi=item.getmodelobject();
link link=new link(link, item.getmodel()) {
onclick() { ((menuitem)getmodelobject()).onclick(); }
}
item.add(link);
link.add(new label(label, mi.getlabel());
}
}
}
Or use bookmarkable links instead of normal links if e.g. you are
building a menu bar that needs to be clickable even if the session
expires.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still calling
into static functions to know what id to give the caption and label.
Plus I had to create an additional class to hold that link plus the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's less
kludgey than what i had earlier.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
heh, if you think inner classes are complex you are def using the wrong
framework
-igor
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still calling
into static functions to know what id to give the caption and label.
Plus I had to create an additional class to hold that link plus the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's less
kludgey than what i had earlier.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
http://www.google.com/search?client=safarirls=enq=listview+wicket+site:cwiki.apache.org/wicketie=UTF-8oe=UTF-8 On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote: Also, not ignoring the fact I needed to have dug in more to the documentation that is there, why doesn't http://wicketstuff.org/wicket13/compref/ mention ListView ? Is there another reference (besides Javadoc) that would discuss more about it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
You should use panels for this. You can have panels for 1 link, 2 links a 3 links. Or even put a repeater into panel to generate as many links as you want. And you then need only one placeholder on the page (for the panel). -Matej 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]
Re: best practice for a header component with links defined by the page
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]
Re: best practice for a header component with links defined by the page
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]
Re: best practice for a header component with links defined by the page
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]
Re: best practice for a header component with links defined by the page
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... That's one way to do it. But a better way typically is to build up your pages dynamically, using panels for content that can change. Or a combination of the two. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
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]
