Re: dependencies
thanks, martijn, i got it now and without a .war file as well.
the servlet api is truly a twisty maze of semi-meaningless terminology.
did you configure your servletcontexthandlerfiltercontextdispatchingfactory
today? :)
On Fri, Oct 7, 2016 at 2:59 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> On Fri, Oct 7, 2016 at 10:43 PM, Jonathan Locke <jonathan.lo...@gmail.com>
> wrote:
>
> > so the quick start is somewhat helpful because it definitely works, but
> the
> > way it works is pretty confusing to me. the code below from the quick
> start
> > was not on any of the documentation pages i was able to google up and it
> > appears (maybe) to be necessary to get web sockets working? what i'd LIKE
> > to do is start jetty using only the programmatic API (with no XML
> > configuration at all), but i'm beginning to wonder if that's even
> possible
> > based on the quick start example. how do you do what the code below does
> > without a WebAppContext? the other examples i was working from until i
> > looked at the quick start were simply installing a JavaxWebSocketFilter
> > instance as a filter. but apparently that's not enough to get a
> connection
> > going and now i'm wondering if this endpoint config isn't the missing
> > ingredient.
> >
> > final ServerContainer serverContainer =
> > WebSocketServerContainerInitializer.configureContext(bb);
> >
> > serverContainer.addEndpoint(new WicketServerEndpointConfig());
> >
>
> This is needed *only* if you use embedded Jetty.
> All examples assume that you use a proper web server where you deploy a
> .war file.
>
>
> >
> >
> > On Thu, Oct 6, 2016 at 10:06 PM, Martin Grigorov <
> > martin.grigo...@gmail.com>
> > wrote:
> >
> > > Please create a quickstart and I'll take a look.
> > >
> > > One thing that I notice is that your app name is the filter class name.
> > > Copy/paste in web.xml. But this probably is not the reason.
> > >
> > > On Oct 7, 2016 5:21 AM, "Jonathan Locke" <jonathan.lo...@gmail.com>
> > wrote:
> > >
> > > > i don't think this is probably a bug in wicket web sockets, but i was
> > > > wondering if you had any hints how to debug this?
> > > >
> > > > one thing i've noticed is that acceptWebSocket always returns false
> in
> > > > AbstractUpgradeFilter because there is no "Upgrade" header set.
> > > >
> > > > if (!headerContainsToken(req, "Upgrade", "websocket"))
> > > >
> > > > {
> > > >
> > > > return false;<--- always returns false
> > > >
> > > > }
> > > >
> > > > this seems bad. does that help narrow it down at all?
> > > >
> > > >jon
> > > >
> > > >
> > > > On Thu, Oct 6, 2016 at 12:41 AM, Martin Grigorov <
> mgrigo...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Here are the docs:
> > > > > https://ci.apache.org/projects/wicket/guide/7.x/
> > > > > guide/nativewebsockets.html#nativewebsockets_2
> > > > >
> > > > > Martin Grigorov
> > > > > Wicket Training and Consulting
> > > > > https://twitter.com/mtgrigorov
> > > > >
> > > > > On Thu, Oct 6, 2016 at 6:21 AM, Jonathan Locke <
> > > jonathan.lo...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > good question! i fought with this all day today and finally
> decided
> > > to
> > > > > > upgrade to wicket 7 and try the javax websockets after a whole
> > series
> > > > of
> > > > > > runtime problems with apparent version conflicts (dear java 9
> > > modules,
> > > > > > hurry up please!). hopefully this will help tomorrow.
> > > > > >
> > > > > > jon
> > > > > >
> > > > > >
> > > > > > On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <
> > > > > martin.grigo...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > What exactly is the problem?
> > > > > > > Which impl of Wicket WebSockets do you use?
> > > > > > >
> > > > > > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" <
> > jonathan.lo...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > trying to find a set of maven dependencies that work for
> > servlet
> > > > api
> > > > > +
> > > > > > > > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
> > > > > > > >
> > > > > > > > does anyone know the magic combination of version numbers?
> > > > > > > >
> > > > > > > > jon
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: dependencies
so the quick start is somewhat helpful because it definitely works, but the
way it works is pretty confusing to me. the code below from the quick start
was not on any of the documentation pages i was able to google up and it
appears (maybe) to be necessary to get web sockets working? what i'd LIKE
to do is start jetty using only the programmatic API (with no XML
configuration at all), but i'm beginning to wonder if that's even possible
based on the quick start example. how do you do what the code below does
without a WebAppContext? the other examples i was working from until i
looked at the quick start were simply installing a JavaxWebSocketFilter
instance as a filter. but apparently that's not enough to get a connection
going and now i'm wondering if this endpoint config isn't the missing
ingredient.
final ServerContainer serverContainer =
WebSocketServerContainerInitializer.configureContext(bb);
serverContainer.addEndpoint(new WicketServerEndpointConfig());
On Thu, Oct 6, 2016 at 10:06 PM, Martin Grigorov <martin.grigo...@gmail.com>
wrote:
> Please create a quickstart and I'll take a look.
>
> One thing that I notice is that your app name is the filter class name.
> Copy/paste in web.xml. But this probably is not the reason.
>
> On Oct 7, 2016 5:21 AM, "Jonathan Locke" <jonathan.lo...@gmail.com> wrote:
>
> > i don't think this is probably a bug in wicket web sockets, but i was
> > wondering if you had any hints how to debug this?
> >
> > one thing i've noticed is that acceptWebSocket always returns false in
> > AbstractUpgradeFilter because there is no "Upgrade" header set.
> >
> > if (!headerContainsToken(req, "Upgrade", "websocket"))
> >
> > {
> >
> > return false;<--- always returns false
> >
> > }
> >
> > this seems bad. does that help narrow it down at all?
> >
> >jon
> >
> >
> > On Thu, Oct 6, 2016 at 12:41 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Here are the docs:
> > > https://ci.apache.org/projects/wicket/guide/7.x/
> > > guide/nativewebsockets.html#nativewebsockets_2
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Thu, Oct 6, 2016 at 6:21 AM, Jonathan Locke <
> jonathan.lo...@gmail.com
> > >
> > > wrote:
> > >
> > > > good question! i fought with this all day today and finally decided
> to
> > > > upgrade to wicket 7 and try the javax websockets after a whole series
> > of
> > > > runtime problems with apparent version conflicts (dear java 9
> modules,
> > > > hurry up please!). hopefully this will help tomorrow.
> > > >
> > > > jon
> > > >
> > > >
> > > > On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <
> > > martin.grigo...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > What exactly is the problem?
> > > > > Which impl of Wicket WebSockets do you use?
> > > > >
> > > > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > trying to find a set of maven dependencies that work for servlet
> > api
> > > +
> > > > > > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
> > > > > >
> > > > > > does anyone know the magic combination of version numbers?
> > > > > >
> > > > > > jon
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: dependencies
i don't think this is probably a bug in wicket web sockets, but i was
wondering if you had any hints how to debug this?
one thing i've noticed is that acceptWebSocket always returns false in
AbstractUpgradeFilter because there is no "Upgrade" header set.
if (!headerContainsToken(req, "Upgrade", "websocket"))
{
return false;<--- always returns false
}
this seems bad. does that help narrow it down at all?
jon
On Thu, Oct 6, 2016 at 12:41 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Here are the docs:
> https://ci.apache.org/projects/wicket/guide/7.x/
> guide/nativewebsockets.html#nativewebsockets_2
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Oct 6, 2016 at 6:21 AM, Jonathan Locke <jonathan.lo...@gmail.com>
> wrote:
>
> > good question! i fought with this all day today and finally decided to
> > upgrade to wicket 7 and try the javax websockets after a whole series of
> > runtime problems with apparent version conflicts (dear java 9 modules,
> > hurry up please!). hopefully this will help tomorrow.
> >
> > jon
> >
> >
> > On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <
> martin.grigo...@gmail.com
> > >
> > wrote:
> >
> > > What exactly is the problem?
> > > Which impl of Wicket WebSockets do you use?
> > >
> > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com>
> > wrote:
> > >
> > > > trying to find a set of maven dependencies that work for servlet api
> +
> > > > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
> > > >
> > > > does anyone know the magic combination of version numbers?
> > > >
> > > > jon
> > > >
> > >
> >
>
Re: dependencies
and now we see why in the JS error console...
WebSocket connection to
'ws://localhost:2016/wicket/websocket?pageId=0=view%3F0=org.apache.wicket.protocol.ws.javax.JavaxWebSocketFilter-14bf9759'
failed: Unexpected response code: 404
not sure what this means though...
On Thu, Oct 6, 2016 at 9:39 AM, Jonathan Locke <jonathan.lo...@gmail.com>
wrote:
> it appears i never get a WebSocketPayload in onEvent. i checked in
> WebSocketBehavior.renderHead and it's getting in there and rendering JS to
> set up the web socket, but it never gets to onConnect.
>
> add(new WebSocketBehavior() {
>
>
> private static final long serialVersionUID =
> 5630063441999050198L;
>
>
> @Override
>
> protected void onConnect(final ConnectedMessage message) {
>
> View.this.webSocketConnection = new WebSocketConnection(
> message); <<<<<<<-- never gets here
>
> logger.log(new Information("Connected " + View.this.
> webSocketConnection));
>
> }
>
> });
>
> ideas?
>
>
>
> 7.4.0
>
>
>
> 9.2.2.v20140723
>
>
>
> 3.1.0
>
>
>
> 2.23.2
>
>
>
> On Thu, Oct 6, 2016 at 9:28 AM, Jonathan Locke <jonathan.lo...@gmail.com>
> wrote:
>
>> well this part is solved now. i believe the issue was that jersey wanted
>> an older jetty and web sockets wanted a newer one. regardless, i'm done
>> upgrading to wicket 7 and there are no longer linkage problems. the issue
>> now is that my web socket connection never happens :) i will re-read the
>> docs you sent. thanks!
>>
>> jon
>>
>>
>> On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <
>> martin.grigo...@gmail.com> wrote:
>>
>>> What exactly is the problem?
>>> Which impl of Wicket WebSockets do you use?
>>>
>>> On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com>
>>> wrote:
>>>
>>> > trying to find a set of maven dependencies that work for servlet api +
>>> > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
>>> >
>>> > does anyone know the magic combination of version numbers?
>>> >
>>> > jon
>>> >
>>>
>>
>>
>
Re: dependencies
btw, one other thing... a small contribution... it might be nice in wicket
8 or 9 to add a class like the one below (i might have commit rights, but
i'm not part of the dev process anymore, so just posting it here). you can
store a WebSocketConnection in your page when you get a call to onConnect
(if i ever do! :)) and also pass it off to a background process that will
eventually call sendToClient(). it could probably be cleaned up or extended
and it probably needs to be debated on the dev list, but i find this a bit
easier to use and think about and it avoids making the user aware of the
underlying application, session and socket key. i'd say maybe just pass
this to onConnect() instead of ConnectedMessage.
public class WebSocketConnection implements Serializable {
private static final long serialVersionUID = -602379112168193015L;
private final String applicationKey;
private final String sessionIdentifier;
private final IKey key;
public WebSocketConnection(final ConnectedMessage message) {
this.applicationKey = message.getApplication().getApplicationKey();
this.sessionIdentifier = message.getSessionId();
this.key = message.getKey();
}
@Override
public boolean equals(final Object object) {
if (object instanceof WebSocketConnection) {
final WebSocketConnection that = (WebSocketConnection) object;
return this.applicationKey.equals(that.applicationKey)
&& this.sessionIdentifier.equals(that.sessionIdentifier)
&& this.key.equals(that.key);
}
return false;
}
@Override
public int hashCode() {
return Objects.hash(this.applicationKey, this.sessionIdentifier,
this.key);
}
public void sendToClient(final String message) {
final IWebSocketConnectionRegistry registry = new
SimpleWebSocketConnectionRegistry();
final IWebSocketConnection connection =
registry.getConnection(Application.get(this.applicationKey),
this.sessionIdentifier, this.key);
if (connection != null && connection.isOpen()) {
try {
connection.sendMessage(message);
} catch (final IOException e) {
e.printStackTrace();
}
}
}
@Override
public String toString() {
return this.applicationKey + "-" + this.sessionIdentifier + "-" +
this.key;
}
}
On Thu, Oct 6, 2016 at 9:39 AM, Jonathan Locke <jonathan.lo...@gmail.com>
wrote:
> it appears i never get a WebSocketPayload in onEvent. i checked in
> WebSocketBehavior.renderHead and it's getting in there and rendering JS to
> set up the web socket, but it never gets to onConnect.
>
> add(new WebSocketBehavior() {
>
>
> private static final long serialVersionUID =
> 5630063441999050198L;
>
>
> @Override
>
> protected void onConnect(final ConnectedMessage message) {
>
> View.this.webSocketConnection = new WebSocketConnection(
> message); <<<<<<<-- never gets here
>
> logger.log(new Information("Connected " + View.this.
> webSocketConnection));
>
> }
>
> });
>
> ideas?
>
>
>
> 7.4.0
>
>
>
> 9.2.2.v20140723
>
>
>
> 3.1.0
>
>
>
> 2.23.2
>
>
>
> On Thu, Oct 6, 2016 at 9:28 AM, Jonathan Locke <jonathan.lo...@gmail.com>
> wrote:
>
>> well this part is solved now. i believe the issue was that jersey wanted
>> an older jetty and web sockets wanted a newer one. regardless, i'm done
>> upgrading to wicket 7 and there are no longer linkage problems. the issue
>> now is that my web socket connection never happens :) i will re-read the
>> docs you sent. thanks!
>>
>> jon
>>
>>
>> On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <
>> martin.grigo...@gmail.com> wrote:
>>
>>> What exactly is the problem?
>>> Which impl of Wicket WebSockets do you use?
>>>
>>> On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com>
>>> wrote:
>>>
>>> > trying to find a set of maven dependencies that work for servlet api +
>>> > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
>>> >
>>> > does anyone know the magic combination of version numbers?
>>> >
>>> > jon
>>> >
>>>
>>
>>
>
Re: dependencies
it appears i never get a WebSocketPayload in onEvent. i checked in
WebSocketBehavior.renderHead and it's getting in there and rendering JS to
set up the web socket, but it never gets to onConnect.
add(new WebSocketBehavior() {
private static final long serialVersionUID =
5630063441999050198L;
@Override
protected void onConnect(final ConnectedMessage message) {
View.this.webSocketConnection = new WebSocketConnection(
message); <<<<<<<-- never gets here
logger.log(new Information("Connected " + View.this.
webSocketConnection));
}
});
ideas?
7.4.0
9.2.2.v20140723
3.1.0
2.23.2
On Thu, Oct 6, 2016 at 9:28 AM, Jonathan Locke <jonathan.lo...@gmail.com>
wrote:
> well this part is solved now. i believe the issue was that jersey wanted
> an older jetty and web sockets wanted a newer one. regardless, i'm done
> upgrading to wicket 7 and there are no longer linkage problems. the issue
> now is that my web socket connection never happens :) i will re-read the
> docs you sent. thanks!
>
> jon
>
>
> On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <martin.grigo...@gmail.com
> > wrote:
>
>> What exactly is the problem?
>> Which impl of Wicket WebSockets do you use?
>>
>> On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com>
>> wrote:
>>
>> > trying to find a set of maven dependencies that work for servlet api +
>> > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey
>> >
>> > does anyone know the magic combination of version numbers?
>> >
>> > jon
>> >
>>
>
>
Re: dependencies
well this part is solved now. i believe the issue was that jersey wanted an older jetty and web sockets wanted a newer one. regardless, i'm done upgrading to wicket 7 and there are no longer linkage problems. the issue now is that my web socket connection never happens :) i will re-read the docs you sent. thanks! jon On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <martin.grigo...@gmail.com> wrote: > What exactly is the problem? > Which impl of Wicket WebSockets do you use? > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com> wrote: > > > trying to find a set of maven dependencies that work for servlet api + > > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey > > > > does anyone know the magic combination of version numbers? > > > > jon > > >
Re: dependencies
good question! i fought with this all day today and finally decided to upgrade to wicket 7 and try the javax websockets after a whole series of runtime problems with apparent version conflicts (dear java 9 modules, hurry up please!). hopefully this will help tomorrow. jon On Wed, Oct 5, 2016 at 8:35 PM, Martin Grigorov <martin.grigo...@gmail.com> wrote: > What exactly is the problem? > Which impl of Wicket WebSockets do you use? > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" <jonathan.lo...@gmail.com> wrote: > > > trying to find a set of maven dependencies that work for servlet api + > > wicket 6.24.0 + jetty 9 + wicket web sockets + jersey > > > > does anyone know the magic combination of version numbers? > > > > jon > > >
dependencies
trying to find a set of maven dependencies that work for servlet api + wicket 6.24.0 + jetty 9 + wicket web sockets + jersey does anyone know the magic combination of version numbers? jon
Re: ajax timer dying
That was a pretty good guess! It's working now, thanks. Jon On Mon, Oct 3, 2016 at 12:28 PM, Sven Meier <s...@meiers.net> wrote: > My guess: > > https://issues.apache.org/jira/browse/WICKET-6191 > > Regards > Sven > > > > Am 03.10.2016 um 20:16 schrieb Tobias Soloschenko: > >> Hi, >> >> maybe https://ci.apache.org/projects/wicket/apidocs/6.x/org/ >> apache/wicket/util/time/Duration.html >> >> Duration.MAXIMUM >> >> kind regards >> >> Tobias >> >> Am 03.10.2016 um 20:07 schrieb Jonathan Locke <jonathan.lo...@gmail.com>: >>> >>> hello all, >>> >>> been a while! i don't quite understand the parameters of this issue i'm >>> running into yet, but i have an AbstractAjaxTimerBehavior that i'm adding >>> to my page in order to handle updates from asynchronous queries. it works >>> great except that *every once in a while* the timer dies and there are no >>> more calls to the timer behavior. has anyone run into this kind of thing? >>> there's no javascript error on the console, so it's not that. my memory >>> is >>> foggy on wicket ajax... is there maybe some special debugging magic i >>> could >>> turn on to figure this out? is there any way to ensure that the timer >>> never >>> dies? >>> >>> thanks, >>> >>> jon >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
ajax timer dying
hello all, been a while! i don't quite understand the parameters of this issue i'm running into yet, but i have an AbstractAjaxTimerBehavior that i'm adding to my page in order to handle updates from asynchronous queries. it works great except that *every once in a while* the timer dies and there are no more calls to the timer behavior. has anyone run into this kind of thing? there's no javascript error on the console, so it's not that. my memory is foggy on wicket ajax... is there maybe some special debugging magic i could turn on to figure this out? is there any way to ensure that the timer never dies? thanks, jon
wicket 6 ajax integration
hello all! having some trouble with the new wicket 6 ajax. it looks much better but i think i'm confused. i'm trying to use AbstractDefaultAjaxBehavior to call back from JS to the server side and for some reason the behavior's renderHead() method isn't even being called. is there something i need to do besides adding the behavior to my panel to get it to render? thanks, jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-6-ajax-integration-tp4671704.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 6 ajax integration
ah, i figured it. the behavior has to be added in onInitialize(). silly me. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-6-ajax-integration-tp4671704p4671705.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
Albuquerque
Just moved to Albuquerque and wondering if there are any Wicket folks around here. Jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Albuquerque-tp4661609.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
Denver
Hey there! Any Wicket people in Denver? I'm going on a trip from the 13th to the 21st of April and wanted to find out a bit about the local tech scene... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Denver-tp4657726.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 guide now available!
Super cool!! Thanks! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-Wicket-guide-now-available-tp4657407p4657460.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
New Web Site
Hello Wicketeers! It's been a long while since I checked in, but I'm glad to see Wicket is still going strong! I'm posting because Steve Jobs recently trashed my iWeb site from beyond the grave and so I have migrated some of that content to WordPress, where I'm hoping to do a bit of blogging on coding once again (mainly things related to Java design, but perhaps some Wicket posts now and then). Here is the URL to my brand new site: http://codeact.wordpress.com If there are links on the Apache Wicket site to my old site (or other sites out there), they are definitely broken and an update would be hugely appreciated. Best, Jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/New-Web-Site-tp4651504.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: Apache Wicket is a Flawed Framework
Why this business about component nesting keeps coming up is really beyond me. If you're running into non-trivial problems with keeping component nesting in sync, you really need to stop what you're doing and back up a step or two because you're definitely looking through the wrong end of the Wicket telescope. If you've got some giant page or panel or form with piles of nested anonymous classes defining a multi-level hierarchy, you're pretty much headed off into the woods. To tap Wicket's OO power you MUST start getting into the habit of breaking things up into appropriate conceptual pieces. Either break them up into reusable panels and/or break them up using these crazy things we have in Java called packages, classes and methods. If I had to paraphrase my book on software design in a sentence, I'd say this: if you break the problem down right, it will solve itself. Java and Wicket provide more than enough to break your problem down into simple pieces so the solution just falls out, without huge complexity all in one place. The real work of software design is all about beating complexity and it has little to do with the pros and cons of any specific technology. It's ALL ABOUT how you conceptualize and then divide and conquer your problem. The rest is a bunch of boring mechanics. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4090715.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: Apache Wicket is a Flawed Framework
Needless to say, I don't particularly agree with most of the criticisms listed. And for the right job, Java isn't half as bad as you seem to think. I'd say the trouble is Java vs. the JDK (and other libraries). While Java itself is still reasonably cool, there is a lot of real crap out there. And there's plenty in the JDK! But if you're determined to program well, you can wrap and hide the majority of this crap quite excellently in Java. What you're left with is a screaming fast server-side programming language with more support in terms of platforms and functionality than anything in history. While I'd love to see a Scala where I can read 90% of the source code out there at a glance like I can with Java, I'll stick with Java (at least on the server side) for now. Given that you hate Wicket and Java (and have a LOT of energy for that given the length of your post), why don't you switch jobs? You sound unhappy with your gig. And although the economy is down, software is actually quite hot and there are a lot of jobs for people that just want to hack on loosely typed UI scripts. Heck, I'm getting emails from headhunters almost daily. I'd say life is too short to lump it. If Wicket doesn't suit you, switch frameworks. If it's required at work and that makes you hate your job, switch jobs. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4085067.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: page expire / ajax error
Yes, that's exactly it. Some weirdness with Tomcat sessions colliding (although not resetting). I have a workaround for now... I simply mount each application on a separate path and it all works. Strange. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/page-expire-ajax-error-tp3915594p3917439.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: Apache Wicket releases Wicket 1.5
Hooray!! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-releases-Wicket-1-5-tp3797412p3797722.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 1.5 and Automatic Link Disabling
Well, even with HEAD of trunk, I'm still not getting link disabling so I may try to create a quickstart. However, those funny errors trying to resolve style.css have a workaround: simply stop using mountPackage and they go away. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-and-Automatic-Link-Disabling-tp3748072p3752598.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 Snapshots in IVY?
Thanks, that's useful information if I have to go back to 1.4 or if 1.5 goes final soon. For now though, I'm looking to use 1.5 snapshot builds (trunk head) as the last RC (1.5-RC5.1) seems to have some problems for me... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Snapshots-in-IVY-tp3750813p3751603.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 1.5 and Automatic Link Disabling
Okay, will do. Thanks Martin!! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-and-Automatic-Link-Disabling-tp3748072p3751604.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 1.5 and Automatic Link Disabling
In Wicket 1.5, the new mountPackage() in combination with wicket:link doesn't seem to create links that automatically disable when you're already on the given page. Is auto-link enable/disable still supported? Thanks! Jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-and-Automatic-Link-Disabling-tp3748072p3748072.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 1.5 and Automatic Link Disabling
Thanks for the thoughts! This is a bit strange. Not only is it not working, but when I add that setAutomaticLinking to my init, it causes further errors... it's apparently trying to resolve package.style.css (no class name)... It's possible it's my fault somehow. I'll debug in the morning, but any ideas are welcome in the meantime! Best, Jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-and-Automatic-Link-Disabling-tp3748072p3748788.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 1.5 and Automatic Link Disabling
Ah, is it possible that this is a problem in the last RC that was fixed in HEAD? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-and-Automatic-Link-Disabling-tp3748072p3749160.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: Copying PageMaps from one session to another
You don't want to copy a page map. If I understand your problem correctly, you may want to check out continueToOriginalDestination(): http://stackoverflow.com/questions/5041879/on-wickets-continuetooriginaldestination-method -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Copying-PageMaps-from-one-session-to-another-tp3571246p3571494.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: Big Brazilian e-Stores using Wicket
Sweet! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Big-Brazilian-e-Stores-using-Wicket-tp3539473p3539633.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: Apache Wicket Cookbook Published!
Cool! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-Cookbook-Published-tp3406012p3415429.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 philosophy, modelObject isVisible, isEnabled, CSS
one other possibility you didn't mention is to nest or layer models. you could use an attribute modifier with a view-adapting model that wraps the data model to provide translation from a pure data model into a value appropriate for the view layer. this would preserve abstraction better. make sense? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-philosophy-modelObject-isVisible-isEnabled-CSS-tp3328174p3330528.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: Is wicket suited for my needs?
I don't think we even have an option to order servers with fewer than 8 cores and 16GB of RAM at my day job. I think our minimum spec could easily handle twice that load (20K sessions) on a single box. And the web tier scales out very easily. Want more sessions, buy more boxes. I would not be worrying about this at all if it were my project. The key is, as always: *DO NOT* PREMATURELY OPTIMIZE! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-wicket-suited-for-my-needs-tp3305543p3307434.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: Is wicket suited for my needs?
10K concurrent *requests* or sessions? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-wicket-suited-for-my-needs-tp3305543p3306071.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
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
Re: My New Book: Now in Dead Tree Format
It's not on amazon.uk just yet, but if you buy it here I believe they will ship it anywhere in the world: https://www.createspace.com/3487090 Createspace is the demand publisher for the book and is also owned by Amazon.com. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p3000477.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: My New Book: Now in Dead Tree Format
Sorry, no. I think the price is pretty reasonable. Especially given the cost/benefit relative to your typical software industry book. You can barely buy two lattes for the price of my e-book here in Seattle and the profit off a copy is about enough to buy me a beer, which I know you want to do!! :) Of course if you'd prefer, I could throw in a couple hundred pages of repetitive, unreadable dreck and add a hundred pages of code listings so the book /looks/ like it has a lot of value and then jack the price of the paperback up to say $49.99. Then it would make sense to give you the e-book for free. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p3000573.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: My New Book: Now in Dead Tree Format
BTW, there are also technical problems with giving you the e-book for free. There is simply no way to do this on Amazon. Even gifting a Kindle book is not possible at the moment. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p3000577.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: My New Book: Now in Dead Tree Format
I very much appreciate the sentiment, but the book stands on its own and nobody owes me more than thanks for starting Wicket. Besides, it would be a slight to certain core developers (they know who they are) who have at this point put in more time than me. If you want to thank the Wicket team, submit bug fixes, help with documentation, get other people to use Wicket, buy some Wicket gear (proceeds to Apache) or make donations to the Apache Foundation. If, on the other hand, you want to get a glimpse inside my head so that you understand the design process I used to create Wicket, buy the book. As far as Wicket itself goes, I think a better understanding of my process may improve your understanding and application of Wicket. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p3000821.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
My New Book: Now in Dead Tree Format
For those of you who were grumbling about not having a Kindle, now you have no excuse :) http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/ Would like to hear feedback from readers, of course. Also if you enjoy it and can make time, please blog it, rate it on Amazon or pass on the word. It's a quick easy read, but also very terse and dense since I've tried to shrink the most interesting things I've got to say about software into roughly 70 pages... so it may stand up to reading more than once. And even if you've got a lot of experience and feel like you've heard it all, it still may get you thinking in a new way or put things you already know in a different light. Enjoy! Jonathan -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p2998832.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: My New Book: Now in Dead Tree Format
Yes, but not for Linux! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/My-New-Book-Now-in-Dead-Tree-Format-tp2998832p2999635.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: Coding - On Software Design Process
You can read the first 10% of any Kindle book for free. It's on the product page on the right hand side where it says Try it free. http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952469.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: Coding - On Software Design Process
Yes. The other 90% is just filler. On Oct 2, 2010, at 7:42 AM, James Carman [via Apache Wicket]ml-node+2952480-1053361343-133...@n4.nabble.com wrote: Did you make sure to put all the best stuff in the first 10% of the book? :) On Sat, Oct 2, 2010 at 10:28 AM, Jonathan Locke [hidden email] wrote: You can read the first 10% of any Kindle book for free. It's on the product page on the right hand side where it says Try it free. http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952469.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] - To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] View message @ http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952480.html To unsubscribe from Coding - On Software Design Process, click here. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952561.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: Coding - On Software Design Process
You can always read it on your Mac or PC (there's a free Kindle reader). Also, there will be a print book. It's just been delayed a bit by some printer issues. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952828.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: Coding - On Software Design Process
Excellent! A few people have pointed out that I didn't include a Table of Contents on the product page. I updated Amazon, but the change won't show up for 2-4 days, so here it is: Table of Contents Introduction About this Book About the Author Acknowledgements Chapter 1 - Practicing the Art Chapter 2 - Creating a Foundation Being Present Feeling Thinking Chapter 3 - Practicing in Reality Incrementalism Questioning Thinking Small Scaling Thought Chapter 4 - Writing Code as Language Precision Grammar Narrative Chapter 5 - Modeling Analysis Synthesis Building Practical Micro-Architectures Improving Java Type Arithmetic Type Enhancers Type Binding Improving Software Industry Process Chapter 6 - Faith Trust Objects Trust Your Team Trust Yourself -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Coding-On-Software-Design-Process-tp2720854p2952139.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
Coding - On Software Design Process
Hello Wicketeers! I recently finished writing a short book (less than 70 pages) on software design process. I wrote this book because I wanted a place to put down some of the most interesting ideas and things I've learned about software design over the years that have been too long for everyday conversations and emails. If you have worked with me or are familiar with my work through Wicket, you will find a lot of things that feel familiar in this book and it may shed some light on some aspects of Wicket's design for you. It's also my hope that it will help people who read it carefully to improve their software design process. You can get it for Kindle using the link below (or better yet, get your pointy-haired boss to get it for you) or if you prefer dead trees, there will be a paperback available on Amazon in a few days. As I say in the introduction, this book is a conversation starter, so I'd be very interested to hear thoughts and reactions from readers. Enjoy! http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA Best, Jon - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should Duration be deprecated?
you're thinking of windows. Martijn Dashorst wrote: On Tue, Jan 26, 2010 at 10:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i thought they were all stored as electrons My vote goes to Umpalumpa's shifting miniature pumpkins on scales Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Should-Duration-be-deprecated--tp27323675p27339042.html Sent from the Wicket - User 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: Should Duration be deprecated?
TimeUnit is icky and storing time values in primitive types is a bad idea. Alexandru Objelean wrote: I was wondering why would wicket need Duration class as long as java provides a similar TimeUnit. Maybe it would be a good idea to deprecate this class encourage usage of TimeUnit? Alex Objelean -- View this message in context: http://old.nabble.com/Should-Duration-be-deprecated--tp27323675p27328738.html Sent from the Wicket - User 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: Help with Wicket Adoption Numbers
you've got to admit it's a short distance between bloody fist fights in a basement for no purpose whatsoever and using struts. Peter Ertl-3 wrote: Struts Club?! That's disgusting :-( Am 11.01.2010 um 22:57 schrieb Jonathan Locke: that's because it's the number one rule! nobody talks about Struts Club. igor.vaynberg wrote: here is an interesting tidbit wicket is on the front page of nabble http://old.nabble.com/ sorted by activity. we are there along maven, jquery, cxf, tomcat, etc. how is the adoption on those? -igor On Thu, Jan 7, 2010 at 6:19 PM, Lester Chua cicowic...@gmail.com wrote: Thanks for the links. I have already submitted them as part of the evaluation process. I'll take a look at the IBM links from scott. Regards, Lester Steve Swinsburg wrote: On the wiki there are some pages to help your cause: http://cwiki.apache.org/WICKET/websites-based-on-wicket.html http://cwiki.apache.org/WICKET/products-based-on-wicket.html as well as blogs talking about Wicket, and lots more useful PR info: http://cwiki.apache.org/WICKET/index.html All the best! cheers, Steve On 08/01/2010, at 11:43 AM, Lester Chua wrote: Hi, I am facing a hurdle that need crossing in my final attempt to push Wicket for use in an organization. I have: 1) Prototyped a small size module 2) Did 2-3 presentations on the key features and advantages of wicket No one is disputing my claims about productivity and good OO code that was the result. BUT, the technology evaluation committee is NOT recommending Wicket because of. of all things. - Wicket's Low Adoption Rate Can I find any numbers to blow this away? My alternative is to accept the finding and work with Struts 2. Which will mean the stack will need to expand to DWR (for security). I REALLY don't want to go there, and am even considering not taking part in this project due to the high risk involved, only 9 months to introduce huge changes to a system that has lots of legacy problems (took about 3 years to build). I think a lot of those years were spent wrestling with the monster that is EJB 1.1. The only way I thought the project can even be on time is to scrap the entire presentation layer (aka Struts) and redo it in Wicket with 1 dedicated developer while the rest of the team work on killing the beast that is EJB 1.1 by refactoring the biz code. Sigh, my choices are stark. It's either to keep the job and plough ahead and probably fail spectacularly 9 months later or go hungry and explain to my wife why we need to spend less on the kid.. It's easy to blame the tech committee but they did help me find wicket by rejecting my initial proposal to build the new system on a (JQuery+JSON+REST) framework, which can be very productive as well, if not as clean as Wicket. Sorry for rambling so much. Is there any way I can demolish the silly low adoption rate argument (omg I still don't believe it can be so lame)? Lester - 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 -- View this message in context: http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27118513.html Sent from the Wicket - User 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 -- View this message in context: http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27132029.html Sent from the Wicket - User 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: Help with Wicket Adoption Numbers
that's because it's the number one rule! nobody talks about Struts Club. igor.vaynberg wrote: here is an interesting tidbit wicket is on the front page of nabble http://old.nabble.com/ sorted by activity. we are there along maven, jquery, cxf, tomcat, etc. how is the adoption on those? -igor On Thu, Jan 7, 2010 at 6:19 PM, Lester Chua cicowic...@gmail.com wrote: Thanks for the links. I have already submitted them as part of the evaluation process. I'll take a look at the IBM links from scott. Regards, Lester Steve Swinsburg wrote: On the wiki there are some pages to help your cause: http://cwiki.apache.org/WICKET/websites-based-on-wicket.html http://cwiki.apache.org/WICKET/products-based-on-wicket.html as well as blogs talking about Wicket, and lots more useful PR info: http://cwiki.apache.org/WICKET/index.html All the best! cheers, Steve On 08/01/2010, at 11:43 AM, Lester Chua wrote: Hi, I am facing a hurdle that need crossing in my final attempt to push Wicket for use in an organization. I have: 1) Prototyped a small size module 2) Did 2-3 presentations on the key features and advantages of wicket No one is disputing my claims about productivity and good OO code that was the result. BUT, the technology evaluation committee is NOT recommending Wicket because of. of all things. - Wicket's Low Adoption Rate Can I find any numbers to blow this away? My alternative is to accept the finding and work with Struts 2. Which will mean the stack will need to expand to DWR (for security). I REALLY don't want to go there, and am even considering not taking part in this project due to the high risk involved, only 9 months to introduce huge changes to a system that has lots of legacy problems (took about 3 years to build). I think a lot of those years were spent wrestling with the monster that is EJB 1.1. The only way I thought the project can even be on time is to scrap the entire presentation layer (aka Struts) and redo it in Wicket with 1 dedicated developer while the rest of the team work on killing the beast that is EJB 1.1 by refactoring the biz code. Sigh, my choices are stark. It's either to keep the job and plough ahead and probably fail spectacularly 9 months later or go hungry and explain to my wife why we need to spend less on the kid.. It's easy to blame the tech committee but they did help me find wicket by rejecting my initial proposal to build the new system on a (JQuery+JSON+REST) framework, which can be very productive as well, if not as clean as Wicket. Sorry for rambling so much. Is there any way I can demolish the silly low adoption rate argument (omg I still don't believe it can be so lame)? Lester - 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 -- View this message in context: http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27118513.html Sent from the Wicket - User 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: Help with Wicket Adoption Numbers
yup. ibm is into it. i also think it's telling that wicket is a global phenomenon at this point... there are books on wicket in english (3), german (2), japanese (1) and chinese (1). and these are independent books, not localizations of one book. jon p.s. if your group needs advice, i occasionally do architectural consulting and there are also a number of trainers out there now. Scott Swank wrote: The wiki has a list of some web sites that use Wicket. http://cwiki.apache.org/WICKET/websites-based-on-wicket.html A quick search of IBM shows approx 1,080 articles on Wicket: http://www.google.com/search?q=site:ibm.com+wicket Scott On Thu, Jan 7, 2010 at 4:43 PM, Lester Chua cicowic...@gmail.com wrote: Hi, I am facing a hurdle that need crossing in my final attempt to push Wicket for use in an organization. I have: 1) Prototyped a small size module 2) Did 2-3 presentations on the key features and advantages of wicket No one is disputing my claims about productivity and good OO code that was the result. BUT, the technology evaluation committee is NOT recommending Wicket because of. of all things. - Wicket's Low Adoption Rate Can I find any numbers to blow this away? My alternative is to accept the finding and work with Struts 2. Which will mean the stack will need to expand to DWR (for security). I REALLY don't want to go there, and am even considering not taking part in this project due to the high risk involved, only 9 months to introduce huge changes to a system that has lots of legacy problems (took about 3 years to build). I think a lot of those years were spent wrestling with the monster that is EJB 1.1. The only way I thought the project can even be on time is to scrap the entire presentation layer (aka Struts) and redo it in Wicket with 1 dedicated developer while the rest of the team work on killing the beast that is EJB 1.1 by refactoring the biz code. Sigh, my choices are stark. It's either to keep the job and plough ahead and probably fail spectacularly 9 months later or go hungry and explain to my wife why we need to spend less on the kid.. It's easy to blame the tech committee but they did help me find wicket by rejecting my initial proposal to build the new system on a (JQuery+JSON+REST) framework, which can be very productive as well, if not as clean as Wicket. Sorry for rambling so much. Is there any way I can demolish the silly low adoption rate argument (omg I still don't believe it can be so lame)? Lester - 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 -- View this message in context: http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27071273.html Sent from the Wicket - User 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: Asynchronous construction of page
i know i'm jumping into this in the middle and maybe someone already proposed this or it's not a good idea for some reason that's not immediately obvious, but i wonder if we could do some lock splitting here (in wicket 1.5?) so that the coarse grained page lock is replaced with a locking system for component subtrees. then multiple ajax updates of different screen areas could happen simultaneously. i believe this could be implemented fairly easily with a Component.getLock() method that chains up the hierarchy looking for locks. the default page lock would be at the top and subtrees that got locked by ajax updates would add new lock objects via Component metadata. of course the page lock would have to be used to add that metadata to prevent a race condition, but it seems like it would work. then again, i'm not intimately familiar with our ajax implementation these days. Kaspar Fischer-2 wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27018131.html Sent from the Wicket - User 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: Asynchronous construction of page
true, but i think the component tree would be locked, not the models. and just to play devil's advocate... such a feature could be off by default and in development mode it could do a complete check of the tree for root model objects being used outside the locked subtree... such that it would be invalid to have a fine-grained lock on a subtree with a model being accessed by components outside that subtree. i'm not saying this is a great idea, just trying to clarify this thinking-out-loud idea... igor.vaynberg wrote: this is still highly error prone. locking a component subtree is not always enough. usually component subtrees share a model object that is somewhere higher up, so it is the component that owns the root model object that needs to be locked. but, once you throw in model chaining into the mix it becomes not so easy to figure out which component should actually own the root lock. -igor On Mon, Jan 4, 2010 at 11:37 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: i know i'm jumping into this in the middle and maybe someone already proposed this or it's not a good idea for some reason that's not immediately obvious, but i wonder if we could do some lock splitting here (in wicket 1.5?) so that the coarse grained page lock is replaced with a locking system for component subtrees. Â then multiple ajax updates of different screen areas could happen simultaneously. i believe this could be implemented fairly easily with a Component.getLock() method that chains up the hierarchy looking for locks. the default page lock would be at the top and subtrees that got locked by ajax updates would add new lock objects via Component metadata. Â of course the page lock would have to be used to add that metadata to prevent a race condition, but it seems like it would work. Â then again, i'm not intimately familiar with our ajax implementation these days. Kaspar Fischer-2 wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27018131.html Sent from the Wicket - User 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 -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27019945.html Sent from the Wicket - User 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 feedback
an interesting question... i had some thoughts about this as related to my sprockets experiment a few years back... http://mail-archives.apache.org/mod_mbox/wicket-users/200804.mbox/%3c16411092.p...@talk.nabble.com%3e unfortunately, i know as little about GWT now as i did then. jon On Dec 23, 2009, at 7:38 AM, Johan Compagner wrote: On Wed, Dec 23, 2009 at 07:32, Sudhir N sudhir_nima...@yahoo.com wrote: One more thing I am still looking for is, integrating GWT. I did that before with other framework. i asked this question more How do you see this integration? What should be integrated. What should wicket do? What should GWT do? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
jobs
not definitely looking yet, but my company was just bought and while that's a good thing, it's unclear to me exactly how everything is going to shake out. so i'm curious what's going on out there. i can provide references from some of the best in the industry. you already have a code sample. :) http://web.me.com/jonathan.locke/JonathanLocke/Resume.html jon - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Java Web Framework poll
Go Wicket! :) Maarten Bosteels wrote: Let's all vote ! Even though they misspelled both Apache and Wicket :-) http://shunmugakrishna.wordpress.com/2009/12/14/what-java-web-application-frameworks-do-you-use/ Maarten - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Java-Web-Framework-poll-tp26818247p26822191.html Sent from the Wicket - User 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: How to make a feedback panel appear on page load?
if i understand you correctly, you can set an error directly on the session (as opposed to on a particular component) and it will display on the target page. Early Morning wrote: Hi, I'm trying to make a feedback panel appear immadiately after page load (such as when you search and the results appear in a new page, but there is an error), but even if I call error(message); no feedback panel appears. What would be the recommended way to do this? Thanks! Regards, Ces -- View this message in context: http://old.nabble.com/How-to-make-a-feedback-panel-appear-on-page-load--tp26586832p26587350.html Sent from the Wicket - User 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: How to render panel markup to string - solved
don't know what you're doing exactly or if i ever tested this one, but this
might be of interest:
http://code.google.com/p/twenty-six-wicket-tricks/source/browse/trunk/twenty-six-wicket-tricks/src/main/java/com/locke/library/web/panels/caching/CachingPanel.java
jon
MartinM wrote:
Hi!
Here is a way to render panel markup to string.
It is a bit of a tweak, I admit, but what can you do.
1. Assume you have components on your page, ready to be rendered.
2. In onBeforeRender, quickly switch one of your existing components
to another that you want to render into a string
3. Let your special component render into a string.
4. Restore back to the original component that was supposed to be
rendered onto the web page.
5. It seems to work ok at least if your component is a panel.
Example code:
---8
somewhere in your page hierarchy that is actually rendered
/**
* @see org.apache.wicket.Page#onBeforeRender()
*/
@Override
protected void onBeforeRender() {
System.out.println(\n-\n
+ MarkupUtils.renderToString(loginForm, new
IntroductionPanel(loginForm.getId(;
super.onBeforeRender();
}
---8
MarkupUtils.public static String renderToString(final Component
parentDonorComponent, final Component component) {
if (!component.getId().equals(parentDonorComponent.getId())) {
throw new IllegalStateException(Component will try to
substitute parentDonorComponent to render. Donor and string render
Component id's must be equal.);
}
final Response originalResponse = RequestCycle.get().getResponse();
StringResponse stringResponse = new StringResponse();
RequestCycle.get().setResponse(stringResponse);
MarkupContainer parentComponent = parentDonorComponent.getParent();
parentComponent.remove(parentDonorComponent);
try {
parentComponent.add(component);
try {
component.prepareForRender();
component.renderComponent();
} catch (RuntimeException e) {
component.afterRender();
throw e;
}
} finally {
// Restore original component
parentComponent.replace(parentDonorComponent);
// Restore original response
RequestCycle.get().setResponse(originalResponse);
}
return stringResponse.toString();
}
**
Martin
2009/10/30 Martin Makundi martin.maku...@koodaripalvelut.com:
Almost still needs some tweaking:
org.apache.wicket.WicketRuntimeException: Unable to find the markup
for the component. That may be due to transparent containers or
components implementing IComponentResolver: [MarkupContainer
[Component id = -]]
  at
org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:125)
  at
org.apache.wicket.Component.locateMarkupStream(Component.java:3813)
  at org.apache.wicket.Component.renderComponent(Component.java:2547)
**
Martin
2009/10/30 Martin Makundi martin.maku...@koodaripalvelut.com:
Looking at AjaxRequestTarget, maybe something like this might work?
        // substitute our encoding response for the real one so
we can capture
        // component's markup in a manner safe for transport
inside CDATA block
        final Response originalResponse = response;
        StringResponse stringResponse = new StringResponse();
        RequestCycle.get().setResponse(stringResponse);
        // Initialize temporary variables
        final Page page = component.findParent(Page.class);
        if (page == null)
        {
            // dont throw an exception but just ignore this
component, somehow
            // it got
            // removed from the page.
            // throw new IllegalStateException(
            // Ajax request attempted on a component that is
not associated
            // with a Page);
            LOG.debug(component: + component + with
markupid: + markupId +
                not rendered because it was already
removed from page);
            return;
        }
        page.startComponentRender(component);
        try
        {
            component.prepareForRender();
            // render any associated headers of the component
            respondHeaderContribution(response, component);
        }
        catch (RuntimeException e)
        {
            try
            {
                component.afterRender();
            }
            catch (RuntimeException e2)
            {
                // ignore this one could be a result off.
            }
Â
Re: Scopes in Wicket Application
except they are type-safe. also, there is component scope. jthomerson wrote: Basically the same. -- Jeremy Thomerson http://www.wickettraining.com On Sun, Nov 8, 2009 at 7:34 AM, sakthi vel vela@gmail.com wrote: Hello, What are the scopes in wicket application much like four different scopes(request, page, session, application) in jsp. -- View this message in context: http://old.nabble.com/Scopes-in-Wicket-Application-tp26253836p26258274.html Sent from the Wicket - User 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: Absolute static file references
it's pure common sense.
don't prematurely optimize is just a version of don't fix what ain't
broke.
luther.baker wrote:
Thanks Igor.
We're not having performance issues. I'm just mapping what we
traditionally
do to Wicket. I did come across
CSSPackageResource.getHeaderContribution(style/default/main.css));
which seems to do exactly what I was looking for.
Back to your point, I guess I understood that Wicket 'could' manage
resources - I'm just not sure when it 'should' manage them. I generally
consider it a best practice to let the server handle static CSS and
potentially huge js and img files but it sounds like you're suggesting
start by managing the resources within Wicket and wait until performance
issues actually start popping up and then consider externalizing them.
What's nice to see is that Wicket appears to handle either approach pretty
well.
Also, ContextImage hit the nail on the head. Thanks for the suggestion
-Luther
On Sat, Oct 24, 2009 at 4:42 PM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
have you actually hit a scalability problem?
if you are trying to optimize upfront you can use a less invasive
technique. all resource urls in wicekt are served under the
/resources/ virtual folder. you can enable the setting where wicket
will append a last-modified date to the end of each resource url, and
then have an apache-side cache to cache and serve everything under
/resources/.
alternatively see how ContextImage works if you want to serve your own
stuff out of webapp folder.
-igor
On Sat, Oct 24, 2009 at 10:53 AM, Luther Baker lutherba...@gmail.com
wrote:
Have another question about serving up CSS (JS, img, etc) files
statically:
a) I'd like to have the option to serve my CSS up statically via an
apache
proxy. I'd also like to avoid serving CSS requests up via the wicket
filter
- even if served up by Jetty - as I think it will scale just a bit
better
...
b) With my current URL mounts, many pages with different base URLs
refer
to
the same CSS file. Consequently, a relative URL for the common CSS
files
as
referenced in the master template won't work since the CSS file would
be
looked up relative to each different URL mount point.
Does that makes sense? So, I would like to create a simple, absolute
reference mechanism for my static CSS, image or other files (without
hardcoding).
I'm not as knowledgeable about the way that components are mapped to
wicket
tags, how to add my own tags or even how to create my own components
(other
than Panels of course). Does the approach below adhere to the wicket
way?
It feels a bit manual ... and I'm not fond of the static WEB_CONTEXT
assignment - but I don't see an elegant/efficient way to get it from
within
the Page or the AbstractBehavior on a per request basis.
Just looking for a bit of advice.
Does the WIKI have some detailed docs that really get into the nitty
gritty
of low-level component and tag design? IE: Details of ComponentTag,
MarkupElement, WicketTag,
On the other hand, is there any strong advice to put custom CSS, image
and
JS files in the classpath and reference ala wicket or is my approach
perfectly reasonable here. An alternate goal of mine to keep custom
components/solutions to a minimum.
Thanks in advance,
-Luther
*MARKUP IN:*
head
link wicket:id=head.link rel=stylesheet
href=style/default/main.css/
/head
*MARKUP OUT:*
head
link rel=stylesheet href=*/portal/*style/default/main.css/
/head
*JAVA*
final static String WEB_CONTEXT =
WebApplication.get().getServletContext().getContextPath();
protected DefaultPageTemplate()
{
//
http://www.mkyong.com/wicket/how-to-dynamic-add-attribute-to-a-html-tag-in-wicket/
final WebMarkupContainerWithAssociatedMarkup cssLink = new
WebMarkupContainerWithAssociatedMarkup(head.link);
add(cssLink);
cssLink.add(new AbstractBehavior()
{
private static final long serialVersionUID = 1L;
@Override
public void onComponentTag(final Component component,
final ComponentTag tag)
{
String href = tag.getAttribute(href);
href = WEB_CONTEXT + / + href;
tag.put(href, href);
}
});
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Absolute-static-file-references-tp26041429p26047592.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional
Re: [WIKI] Websites based on Wicket page presentation
shouldn't it be one of igor's famous tables with the sort headers? then we wouldn't need to argue over how to order it. jWeekend wrote: I've been having some very brief communication with Ralf Eichinger who has been making a valuable contribution over the last few weeks by starting to improve documentation on the Wiki, especially with a view to help people evaluating Wicket get a fairer appreciation of it, who's using it and what they are doing with it. Now obviously it is extremely valuable for newcomers to have a page like our Websites based on Wicket [1] to get a feel for who's doing what with Wicket already. And, for apps built on Wicket, like Leg Up and all those other Wicket sites, it is nice to have a central place to put a link on that others may come across and therefore be aware it's out there, and enjoy visiting/using it. It's also encouraging to see this list of apps and sites grows, albeit steadily (I recommend anyone with a public Wicket app to mention it there, it can only do good for all concerned, AFAICS). All the same, there are increasingly more sophisticated and impressive sites highlighting the strength and depth of the community/developers and what magic can be weaved using Wicket (whilst developers amongst us also know that in Wicket such magic is possible at the same time as keeping your application design and code neat, tidy, maintainable and extensible and even rather pleasant to work with). One question that came up is whether the pages listed by URL there should be ordered alphabetically or chronologically. For me, chronological (newest at top, as had been the case originally) makes much more sense because when I look at the site, I can see how things have evolved, quickly identify what's new since I last looked and also answer questions like what were the first public Wicket sites listed here?. This is also a much more robust sorting scheme (people _like_ to add their shiny new apps/sites to the top of the list!) and with no arbitrary rules there's not such a likelihood of breaking the sort order every time anyone adds their site (eg should http://www.eropuit.nl go before or after fabulously40.com), as it was when I went in to add LegUp. Chronological ordering is a scheme that was always quite naturally maintained and therefore required no further maintenance to keep right. What's more, I don't see what the benefit of an artificial sort ordering like alphabetically ordered by URL would be in this context as I doubt anyone looking at the page is not familiar with Ctrl+F if they come looking for some specific page/site/URL. I doubt anyone else has ever been worried about this, but if anyone else has a view on it I'd be pleased to know about it and if there are some good reasons for alphabetically ordering too the list that I have missed I can stop messing up Ralf's order! Regards - Cemal jWeekend OO Java Technologies, Wicket Training and Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/-WIKI--%22Websites-based-on-Wicket%22-page-presentation-tp25880274p25884516.html Sent from the Wicket - User 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: Question about wicket validation
protected final void validate()
{
if (isEnabledInHierarchy() isVisibleInHierarchy())
{
// since this method can be called directly by users,
this additional
check is needed
validateComponents();
validateFormValidators();
onValidate();
validateNestedForms();
}
}
MartinM wrote:
Hi!
If a form validator depends on a nested form's components, it will
assume they are valid because the nested form's components are
validated after the parent form?
**
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Question-about-wicket-validation-tp25657602p25669362.html
Sent from the Wicket - User 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: Can anyone share a ReCaptcha Panel?
why not use kitten captcha? fatefree wrote: I saw there was an archived post about a panel that was created for this purpose, but the code was shared through PasteBin and it seems the urls are old and possibly, filled with some kind of virus. Does anyone still have or know of a complete recaptcha panel that can be shared? -- View this message in context: http://www.nabble.com/Can-anyone-share-a-ReCaptcha-Panel--tp25651680p25655010.html Sent from the Wicket - User 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: Article in german Javamagazin
thanks. and thanks to everyone at javamagazin! my copy is now sitting next to my japanese wicket book. Michael Plöd wrote: Hi Jonathan, I was one of the guys writing the title story. I contacted the Java Magazin Team regarding a copy for you! Unfortunately we can't put the articles online for free since they were written for a commercial print magazine. Regards, Michael On Thu, Sep 3, 2009 at 8:13 PM, Jonathan Lockejonathan.lo...@gmail.com wrote: if anyone from javamagazin is reading this list, would love to add a copy of this to my growing collection of wicket publications. RaBe wrote: yes, it is. http://it-republik.de/jaxenter/java-magazin-ausgaben/Wicket-000321.html could not find a online version of this article .. On Thu, Sep 3, 2009 at 18:19, Jonathan Lockejonathan.lo...@gmail.com wrote: btw, is this a print magazine? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Article-in-german-Javamagazin-tp25255240p25281388.html Sent from the Wicket - User 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 -- View this message in context: http://www.nabble.com/Article-in-german-Javamagazin-tp25255240p25439220.html Sent from the Wicket - User 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: Article in german Javamagazin
btw, is this a print magazine? Rüdiger_Schulz wrote: Hello everybody, the next issue of german Javamagazin (http://www.javamagazin.de/) has their title story about Wicket. It consists of two articles. One technical one, showing basic setup and principles of Wicket, and another about practical use of the framework. Despite constructive criticism (e.g. Wiki needs much better structuring to find anything useful, markup hierarchy and wicket:ids have to match Java code, without tool support for refactoring) they give a strong recommendation for using Wicket, and regard it on par with the industry standard JSF. So thumbs up to all of you Wicket devs, and hopefully this will lead to a little wider spreading of Wicket! greetings from Berlin, Rüdiger Schulz -- View this message in context: http://www.nabble.com/Article-in-german-Javamagazin-tp25255240p25279403.html Sent from the Wicket - User 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: Article in german Javamagazin
if anyone from javamagazin is reading this list, would love to add a copy of this to my growing collection of wicket publications. RaBe wrote: yes, it is. http://it-republik.de/jaxenter/java-magazin-ausgaben/Wicket-000321.html could not find a online version of this article .. On Thu, Sep 3, 2009 at 18:19, Jonathan Lockejonathan.lo...@gmail.com wrote: btw, is this a print magazine? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Article-in-german-Javamagazin-tp25255240p25281388.html Sent from the Wicket - User 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: Article in german Javamagazin
nice! Rüdiger_Schulz wrote: Hello everybody, the next issue of german Javamagazin (http://www.javamagazin.de/) has their title story about Wicket. It consists of two articles. One technical one, showing basic setup and principles of Wicket, and another about practical use of the framework. Despite constructive criticism (e.g. Wiki needs much better structuring to find anything useful, markup hierarchy and wicket:ids have to match Java code, without tool support for refactoring) they give a strong recommendation for using Wicket, and regard it on par with the industry standard JSF. So thumbs up to all of you Wicket devs, and hopefully this will lead to a little wider spreading of Wicket! greetings from Berlin, Rüdiger Schulz -- View this message in context: http://www.nabble.com/Article-in-german-Javamagazin-tp25255240p25268588.html Sent from the Wicket - User 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
Java/Wicket Job Available with Wicket founder at Networks in Motion
My company is hiring someone (ideally in Seattle, but we also have an Aliso Viejo office down near L.A.) We are doing a lot of back-end server work in Java, but we would really prefer someone with solid Wicket experience for a variety of reasons. The team is me and one other guy, so there would be three coders after this hire. We really need a high quality and highly productive person. Our company is doing really well and our group is small and fun and focussed on simple, appropriately architected OO and OSS solutions. http://seattle.craigslist.org/see/sof/1311327500.html Thanks, Jonathan Locke - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Failed to handle wicket:container
it would be nice to improve the error message, but i'm no longer working on this project so it's not that important to me personally. thanks for your response. jon Antoine van Wel wrote: replace the wicket:container by a div, and a better error message may appear. in my case the error appeared for a wrong wicket:id (using 1.3.6) it would be helpful if the error message made more sense, shall i file a jira issue for this? (don't know if the same message occurs in 1.4) Antoine On Thu, Apr 10, 2008 at 1:20 AM, Jonathan Locke jonathan.lo...@gmail.comwrote: I am currently trying to debug a markup handling problem where Wicket is complaining that it Failed to handle: wicket:container wicket:id=xyz I suspect that the problem is mine as I am mucking around with content types to deal with mobile devices. Any ideas on what might be wrong or what might be a good approach for debugging this? Also, I've changed markup loading a bit so it switches back and forth between .wml and .html files (falling back on the .html if the .wml does not exist). Would this cause any havoc with resolving this wicket:container tag? Thanks, Jon -- View this message in context: http://www.nabble.com/Failed-to-handle-wicket%3Acontainer-tp16598980p16598980.html Sent from the Wicket - User 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 -- --8--8-- take your photos everywhere you go - http://www.memolio.com --8--8-- We don't see things as they are, we see things as we are. - Anais Nin Whether you think you can or whether you think you can't, you're right. - Henry Ford --8--8-- -- View this message in context: http://www.nabble.com/Failed-to-handle-wicket%3Acontainer-tp16598980p24300483.html Sent from the Wicket - User 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: AW: How to avoid code duplication on forms?
the advantage to subclassing is that you're working better with the type
system whereas static pulls you out of the object world and should be used
with great caution. for example, subclassing enables more subclassing and
therefore more reusability. static factory methods cannot be specialized. i
also feel it's more intuitive to users for something like this. if you want
to see all the textfields on your project and you subclass textfield, you
can bring up textfield and hit F4 in eclipse and see the class hierarchy.
static factory methods are a bit more hidden to quick inspection. i like
static factory methods for things like units (Distance.meters(...) versus
Distance.feet(...)) or if you want to vary the subclass returned.
one improvement i'd make:
public class EmailField extends TextField
and write an EmailConverter. another reason subclassing is best.
Christian Helmbold-2 wrote:
I think the difference between sub classing and static factory methods is
a matter of taste in this case.
If I have many fields, I'd need many classes for them. So I'd group them
in a sub package. In the case of factory methods I'd group the methods to
create fields in a class instead of a package.
Subclass:
1class UserEmailField extends TextField {
2 public UserEmailField(String id, IModel model) {
3super(id, model);
4setRequired(true);
5add(EmailAddressValidator.getInstance())
6add(UniqueValidator.unique(SystemUser.class, email));
7 }
8}
Factory method:
1public static TextField emailTextField(String id){
2return (TextField) new TextField(id)
3.setRequired(true)
4.add(EmailAddressValidator.getInstance())
5.add(UniqueValidator.unique(SystemUser.class,
email));
6}
Your answer shows me, that there is no dramatically simpler way to do
this. If you ignore the two lines for factory class declaration factory
methods are even a bit shorter. Or is there an advantage of sub classing
that I have missed?
Regards,
Christian
- Ursprüngliche Mail
Von: Igor Vaynberg igor.vaynb...@gmail.com
An: users@wicket.apache.org
Gesendet: Freitag, den 8. Mai 2009, 09:08:34 Uhr
Betreff: Re: How to avoid code duplication on forms?
much simpler
class UserEmailField extends TextField {
public UserEmailField(String id, IModel model) {
super(id, model);
add(EmailAddressValidator.getInstance())
add(UniqueValidator.unique(SystemUser.class, email));
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/How-to-avoid-code-duplication-on-forms--tp23440920p23445544.html
Sent from the Wicket - User 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: AW: How to avoid code duplication on forms?
the advantage to subclassing is that you're working better with the type
system whereas static pulls you out of the object world and should be used
with great caution. for example, subclassing enables more subclassing and
therefore more reusability. static factory methods cannot be specialized. i
also feel it's more intuitive to users for something like this. if you want
to see all the textfields on your project and you subclass textfield, you
can bring up textfield and hit F4 in eclipse and see the class hierarchy.
static factory methods are a bit more hidden to quick inspection. i like
static factory methods for things like units (Distance.meters(...) versus
Distance.feet(...)) or if you want to vary the subclass returned.
one improvement i'd make:
public class EmailField extends TextField
and write an EmailConverter. another reason subclassing is best.
Christian Helmbold-2 wrote:
I think the difference between sub classing and static factory methods is
a matter of taste in this case.
If I have many fields, I'd need many classes for them. So I'd group them
in a sub package. In the case of factory methods I'd group the methods to
create fields in a class instead of a package.
Subclass:
1class UserEmailField extends TextField {
2 public UserEmailField(String id, IModel model) {
3super(id, model);
4setRequired(true);
5add(EmailAddressValidator.getInstance())
6add(UniqueValidator.unique(SystemUser.class, email));
7 }
8}
Factory method:
1public static TextField emailTextField(String id){
2return (TextField) new TextField(id)
3.setRequired(true)
4.add(EmailAddressValidator.getInstance())
5.add(UniqueValidator.unique(SystemUser.class,
email));
6}
Your answer shows me, that there is no dramatically simpler way to do
this. If you ignore the two lines for factory class declaration factory
methods are even a bit shorter. Or is there an advantage of sub classing
that I have missed?
Regards,
Christian
- Ursprüngliche Mail
Von: Igor Vaynberg igor.vaynb...@gmail.com
An: users@wicket.apache.org
Gesendet: Freitag, den 8. Mai 2009, 09:08:34 Uhr
Betreff: Re: How to avoid code duplication on forms?
much simpler
class UserEmailField extends TextField {
public UserEmailField(String id, IModel model) {
super(id, model);
add(EmailAddressValidator.getInstance())
add(UniqueValidator.unique(SystemUser.class, email));
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/How-to-avoid-code-duplication-on-forms--tp23440920p23445543.html
Sent from the Wicket - User 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: AW: How to avoid code duplication on forms?
uh that was:
class EmailField extends TextField[Email]
where the square brackets are angle brackets :)
Christian Helmbold-2 wrote:
I think the difference between sub classing and static factory methods is
a matter of taste in this case.
If I have many fields, I'd need many classes for them. So I'd group them
in a sub package. In the case of factory methods I'd group the methods to
create fields in a class instead of a package.
Subclass:
1class UserEmailField extends TextField {
2 public UserEmailField(String id, IModel model) {
3super(id, model);
4setRequired(true);
5add(EmailAddressValidator.getInstance())
6add(UniqueValidator.unique(SystemUser.class, email));
7 }
8}
Factory method:
1public static TextField emailTextField(String id){
2return (TextField) new TextField(id)
3.setRequired(true)
4.add(EmailAddressValidator.getInstance())
5.add(UniqueValidator.unique(SystemUser.class,
email));
6}
Your answer shows me, that there is no dramatically simpler way to do
this. If you ignore the two lines for factory class declaration factory
methods are even a bit shorter. Or is there an advantage of sub classing
that I have missed?
Regards,
Christian
- Ursprüngliche Mail
Von: Igor Vaynberg igor.vaynb...@gmail.com
An: users@wicket.apache.org
Gesendet: Freitag, den 8. Mai 2009, 09:08:34 Uhr
Betreff: Re: How to avoid code duplication on forms?
much simpler
class UserEmailField extends TextField {
public UserEmailField(String id, IModel model) {
super(id, model);
add(EmailAddressValidator.getInstance())
add(UniqueValidator.unique(SystemUser.class, email));
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/How-to-avoid-code-duplication-on-forms--tp23440920p23445578.html
Sent from the Wicket - User 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: Logging for performance analysis
yeah, i think yourkit is the way to go. Martijn Dashorst wrote: At my job we were able to connect yourkit to our production server and diagnose the problem in that way. If you have such spikes, it usually is the garbage collector trying to clean up. Martijn On Mon, Apr 27, 2009 at 10:39 PM, Douglas Ferguson doug...@douglasferguson.us wrote: We are experiencing some hard to trace performance issues (CPU pegged by JAVA). so we want to implement some logging in order to Audit the code. Any suggestions on wicket state that we can easily print out? I.E. size of page map? Etc? D/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Logging-for-performance-analysis-tp23264635p23291442.html Sent from the Wicket - User 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: Turning off ModificationWatcher
Oh, it's MUCH worse than even that. Every single component constructed by your application will get a complete Java stack trace attached to it at the point of construction. Not only does that seriously damage your performance, but this stack trace also takes up space! This is why we warn you about not deploying in development mode on startup. Martin Voigt-2 wrote: Na, nothing catastrophic will happen, or else you won't be able to development your app using development configuration...HOWEVER...the performance of your app is likely to double when running in deployment mode, some exceptions won't be visible to the user (i think component-in-use-check and others), serialization checks won't slow you down, that kind of stuff. If you look at the WebApplication class, you will find lots of getters like getRequestSettings(), getApplicationSettings() and so forth, from what I know, development configuration is a defined set of these configs which sorely focus on helping you while developing, but they won't help you at all while running in production mode, cos they're not optimized for that. On the other hand, deployment configuration is a defined set of these configs which sorely help you getting performance and be in production. It's like running your app with logging on trace level when in development...If your app is any good, it may be it won't harm you at all (we had an app out in production running in development mode for weeks), but your performance will suffer for sure. bw, Martin 2009/4/10 Sam Stainsby s...@sustainablesoftware.com.au: On Thu, 09 Apr 2009 08:41:20 +0200, Martijn Dashorst wrote: Never *EVER* deploy your application in development mode. Use deployment mode and turn those features you want on. Just curious - does something catastrophic happen? I'm running a testing demo for a client and haven't bothered turning off development mode (I assume it is on by default?). It runs fine. Cheers, Sam. - 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 -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p22981611.html Sent from the Wicket - User 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: Turning off ModificationWatcher
Oh, it's MUCH worse than even that. Every single component constructed by your application will get a complete Java stack trace attached to it at the point of construction. Not only does that seriously damage your performance, but this stack trace also takes up space! This is why we warn you about not deploying in development mode on startup. Martin Voigt-2 wrote: Na, nothing catastrophic will happen, or else you won't be able to development your app using development configuration...HOWEVER...the performance of your app is likely to double when running in deployment mode, some exceptions won't be visible to the user (i think component-in-use-check and others), serialization checks won't slow you down, that kind of stuff. If you look at the WebApplication class, you will find lots of getters like getRequestSettings(), getApplicationSettings() and so forth, from what I know, development configuration is a defined set of these configs which sorely focus on helping you while developing, but they won't help you at all while running in production mode, cos they're not optimized for that. On the other hand, deployment configuration is a defined set of these configs which sorely help you getting performance and be in production. It's like running your app with logging on trace level when in development...If your app is any good, it may be it won't harm you at all (we had an app out in production running in development mode for weeks), but your performance will suffer for sure. bw, Martin 2009/4/10 Sam Stainsby s...@sustainablesoftware.com.au: On Thu, 09 Apr 2009 08:41:20 +0200, Martijn Dashorst wrote: Never *EVER* deploy your application in development mode. Use deployment mode and turn those features you want on. Just curious - does something catastrophic happen? I'm running a testing demo for a client and haven't bothered turning off development mode (I assume it is on by default?). It runs fine. Cheers, Sam. - 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 -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p22981612.html Sent from the Wicket - User 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: Turning off ModificationWatcher
not sure, but try getResourceSettings().setResourcePollFrequency(null) in your app init Matt Welch wrote: I'm experimenting with Wicket inside Google's new Java support for its App Engine. My simple apps run fine if the configuration is set to DEPLOYMENT, however in development mode, I get an exception related to ModificationWatcher. Looking at the exception I think this ModificationWatcher is being used as part of a new thread which is a no-no inside the App Engine sandbox. Is there way way to just disbable this modification watcher without putting the entire app in deployment mode? There are a number of items I like about development mode but this one glitch is preventing me from using it. Matt -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p22963737.html Sent from the Wicket - User 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 and (or) restlet
interesting. yeah, igor's right. wicket is not for web services. i prefer jersey to restlet and jersey plays fine with wicket. Casper Bang-3 wrote: restlet is for building services not uis, that quote makes absolutely no sense. While I agree the quote smells of FUD, one doesn't necessarily exclude the other. The beauty of REST is its statelessness, addressability, representation negotiation, caching and other ways it embraces HTTP rather than run away from it (and use overloaded POST's with tiny RPC handlers for everything). In Jersey it's also possible to serve (dynamic) HTML through a standard templating engine, I'm doing this currently and achieving very high scalability while keeping things simple. The caveat with this approach is that you are stuck to the classic templating model and components don't really exist apart from whatever jQuery/ExtJS stuff you wire up manually. So probably like the OP, I can't help but wonder about the possebility of Wicket running on top as a model-view technology - or perhaps just a programming model adopted after Wicket. /Casper -- View this message in context: http://www.nabble.com/Wicket-and-%28or%29-restlet-tp22822162p22832474.html Sent from the Wicket - User 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 and (or) restlet
well, i'd be the first to admit i don't know either of these two products deeply, but for the kinds of applications i have for web services, i found jersey to have really easy, transparent support for request parameter processing. you just annotate some parameters, create a jaxb schema and add an @Path attribute and you've pretty much got a web service. although it looks like a nice architecture that sticks to REST terminology, i at least couldn't find how restlet made some of this grunt work easy (but then maybe i missed that somehow). Alexandru Objelean wrote: Jonathan, can you elaborate? Why do you think jersey is better? Have you any experience of integrating it with wicket? Thanks! Jonathan Locke wrote: interesting. yeah, igor's right. wicket is not for web services. i prefer jersey to restlet and jersey plays fine with wicket. Casper Bang-3 wrote: restlet is for building services not uis, that quote makes absolutely no sense. While I agree the quote smells of FUD, one doesn't necessarily exclude the other. The beauty of REST is its statelessness, addressability, representation negotiation, caching and other ways it embraces HTTP rather than run away from it (and use overloaded POST's with tiny RPC handlers for everything). In Jersey it's also possible to serve (dynamic) HTML through a standard templating engine, I'm doing this currently and achieving very high scalability while keeping things simple. The caveat with this approach is that you are stuck to the classic templating model and components don't really exist apart from whatever jQuery/ExtJS stuff you wire up manually. So probably like the OP, I can't help but wonder about the possebility of Wicket running on top as a model-view technology - or perhaps just a programming model adopted after Wicket. /Casper -- View this message in context: http://www.nabble.com/Wicket-and-%28or%29-restlet-tp22822162p22833918.html Sent from the Wicket - User 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: Picket Web Framework -- PHP's answer to Java's Wicket
will this include SHARKS with FRICKIN' LASER BEAMS attached to their heads? Otan wrote: Are you a fan of Wicket but you can't use it because your company or client is tied with PHP? Have you ever wished that Wicket was available in the PHP land? Picket to the rescue! Picket is a project that aims to bring Wicket's awesome features and philosophy to the PHP community. The project was started by YouSoft Consulting (Nasdaq: YSFT) and being used internally since 2006. Now that Picket 1.1 has been released, and is stable enough for prime time, YouSoft opened the source code for public consumption with multi-licenses, namely, GPL v2, GPL v3, BSD, Apache, MPL and CDDL. For more information, visit its official website at http://4thmonth.yousoft.com/1stday/picket Have a happy day! -- View this message in context: http://www.nabble.com/Picket-Web-FrameworkPHP%27s-answer-to-Java%27s-Wicket-tp22820258p22834990.html Sent from the Wicket - User 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: nested loop view
i think you mean to add the projects listview to the categories list view
/item/
your structure is a little dangerous here because you have one ListItem item
obscuring the other. if the outer one were called outerItem and the inner
one
were called innerItem, i think you meant to say outerItem.add(projects) and
innerItem.add(link)
luther.baker wrote:
I'm trying to create a page - similar to Jira's BROWSE PROJECTS.
My initial take amounts to a loop in a loop.
The outer loop is CATEGORIES and the inner loop is PROJECTS in said
category.
| CATEGORY 1
| p1
| p2
| p3
| CATEGORY 2
| p4
| p5
| p6
...
I've attached code below but if I removed the nested loop, I can easily
loop
over just CATEGORIES but as soon as I add the nested loop, it fails with
the
following
WicketMessage: Error attaching this container for rendering: [Page class =
com.fuzzybearings.milestones.web.page.user.ProjectsPage, id = 3, version =
0]
Root cause:
java.lang.IllegalArgumentException: A child with id 'projects' already
exists:
[MarkupContainer [Component id = categories]]
My intuition tells me that 'wicket:id=projects' is repeating since it is
contained in an outer loop ... but I'm not sure how else to identify this
type of structure in a general way. Is there a loop container more suited
to
this ... open to suggestions.
Thanks in advance,
-Luther
*.html snippet
div wicket:id=categories
table
tr wicket:id=projects
td # [project] /td
/tr
/table
/div
*.java snippet
public ProjectsPage(ResourceModel bodyTitle)
{
super(bodyTitle);
ListView categories = new ListView(categories,
this.getCategories())
{
@Override
protected void populateItem(ListItem item)
{
Category category = (Category) item.getModelObject();
ListView projects = new ListView(projects,
ProjectsPage.this.getProjects(category))
{
@Override
protected void populateItem(ListItem item)
{
Project project = (Project) item.getModelObject();
Link link = new Link(projectLink,
item.getModel())
{
@Override
public void onClick() { ... }
};
link.add(new Label(projectLabel,
project.getName()));
item.add(link);
}
};
this.add(projects);
}
};
this.add(categories);
}
--
View this message in context:
http://www.nabble.com/nested-loop-view-tp22726252p22726455.html
Sent from the Wicket - User 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: nested loop view
uh, well maybe not dangerous, just less clear than it could be.
Jonathan Locke wrote:
i think you mean to add the projects listview to the categories list view
/item/
your structure is a little dangerous here because you have one ListItem
item
obscuring the other. if the outer one were called outerItem and the inner
one
were called innerItem, i think you meant to say outerItem.add(projects)
and
innerItem.add(link)
luther.baker wrote:
I'm trying to create a page - similar to Jira's BROWSE PROJECTS.
My initial take amounts to a loop in a loop.
The outer loop is CATEGORIES and the inner loop is PROJECTS in said
category.
| CATEGORY 1
| p1
| p2
| p3
| CATEGORY 2
| p4
| p5
| p6
...
I've attached code below but if I removed the nested loop, I can easily
loop
over just CATEGORIES but as soon as I add the nested loop, it fails with
the
following
WicketMessage: Error attaching this container for rendering: [Page class
=
com.fuzzybearings.milestones.web.page.user.ProjectsPage, id = 3, version
=
0]
Root cause:
java.lang.IllegalArgumentException: A child with id 'projects' already
exists:
[MarkupContainer [Component id = categories]]
My intuition tells me that 'wicket:id=projects' is repeating since it
is
contained in an outer loop ... but I'm not sure how else to identify this
type of structure in a general way. Is there a loop container more suited
to
this ... open to suggestions.
Thanks in advance,
-Luther
*.html snippet
div wicket:id=categories
table
tr wicket:id=projects
td # [project] /td
/tr
/table
/div
*.java snippet
public ProjectsPage(ResourceModel bodyTitle)
{
super(bodyTitle);
ListView categories = new ListView(categories,
this.getCategories())
{
@Override
protected void populateItem(ListItem item)
{
Category category = (Category) item.getModelObject();
ListView projects = new ListView(projects,
ProjectsPage.this.getProjects(category))
{
@Override
protected void populateItem(ListItem item)
{
Project project = (Project)
item.getModelObject();
Link link = new Link(projectLink,
item.getModel())
{
@Override
public void onClick() { ... }
};
link.add(new Label(projectLabel,
project.getName()));
item.add(link);
}
};
this.add(projects);
}
};
this.add(categories);
}
--
View this message in context:
http://www.nabble.com/nested-loop-view-tp22726252p22726482.html
Sent from the Wicket - User 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: OT: Code Search Engine for Java using wicket
hey wow, this is something i might actually use on a regular basis. thanks! Vinayak Borkar wrote: Hello fellow Wicketeers, We have released a beta version of a code search engine for open source Java code, that uses Wicket v1.4. You could search for wicket by following the link: http://grepcode.com/search/?query=wicket Thanks for all the help you guys have been, with my wicket related problems. Any feedback would be appreciated. Thanks, Vinayak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/OT%3A-Code-Search-Engine-for-Java-using-wicket-tp22694704p22695793.html Sent from the Wicket - User 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 Meetup Tonight in Amsterdam!
So true! So true! Can someone tell me what the surprise was afterwards? ;-) I'll still be surprised on account of not knowing what it was since Seattle is a bit too far from Amsterdam. Darn, I kinda miss Holland right now... jon Linda van der Pal wrote: You'll just have to wait for them to surprise you! ;) Daan van Etten wrote: What's the surprise?! I'm very curious now, can't wait! See you all tonight... Regards, Daan van Etten Op 24 mrt 2009, om 10:22 heeft Martijn Dashorst het volgende geschreven: The Apache Wicket Meetup in Amsterdam tonight (24 March) has grown considerably: over 70 people have already registered! Our program is still growing and just this morning we got an additional presentation! The Meetup is free thanks to our generous sponsors: - Hippo (http://onehippo.com) - Func (http://func.nl) - Topicus (http://topicus.nl) You can still join us between 19:00 and 22:00 in the Moevenpick hotel in Amsterdam. Register for free here: https://spreadsheets.google.com/viewform?formkey=cDFlMTdSV3dKT1lkYUlVa2lWUFdkQXc6MA Route to the venue: http://maps.google.com/maps?client=safarirls=en-usoe=UTF-8um=1ie=UTF-8cid=0,0,16474381925794425644fb=1split=1dq=moevenpick+hotel+amsterdam+piet+heinkadedaddr=Piet+Heinkade+11,+1019+BR+Amsterdam,+Netherlandsgeocode=10995011565374881002,52.378048,4.914107ei=e5fISb-PIsS4-Qb1_tGZAwsa=Xoi=local_resultresnum=1ct=directions-to Program: - Introduction to Wicket - Wicket Scala - Surprise - Wicket JDave - Automated integration testing for Wicket apps - Wicket DB4O - Getting your app production ready and in production Of course there is room for questions to the core team (Timo, Johan and Martijn are present), getting your book signed or just have a beer. See you tonight! -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: 270.11.25/2019 - Release Date: 03/23/09 18:51:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Wicket-Meetup-Tonight-in-Amsterdam%21-tp22676632p22691202.html Sent from the Wicket - User 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: How can I share text resources with multiple web applications?
yes, but wicket takes a different view than maven on resources in general. they are always closest to the component they belong to. it's a form of encapsulation. so maybe it's wrong from maven's point of view, but putting them in src/main/resources would be wrong from wicket's point of view. the archetype should remain unchanged. Brill Pappin wrote: With Maven, non compiled files should be in src/main/resources The quickstart archetype actually does the *wrong* thing and puts them in with the java files. - Brill Pappin On 18-Mar-09, at 4:19 PM, Trent Larson wrote: Thanks for the suggestion. For posterity's sake: my problem was actually with the Maven 2 build, where it ignored the properties file (located in with the Java files) when it built the jar project. Trent On Mon, Mar 16, 2009 at 5:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: see iresourcesettings#addstringresourceloader() make one that loads your properties from some file you keep on the classpath -igor On Mon, Mar 16, 2009 at 4:00 PM, Trent Larson larsontr...@gmail.com wrote: I have 2 web applications, and I would like to allow them to share the same text files. The only way I've found is to make each WebApplication class extend a common ParentApplication class and make a ParentApplication.properties file to contain the common text; then I package the common ParentApplication class and properties in a separate jar project and include that in each of the web projects. This works great in Eclipse in an exploded environment; unfortunately, it looks like it does not work when I include the ParentApplication artifacts inside a separate jar. I get the following error: Caused by: java.util.MissingResourceException: Unable to find property: ' squeeze.presented.by' for component: [class=com.max.web.page.bizopp1Page] at org.apache.wicket.Localizer.getString(Localizer.java:269) . Is there any way to make this work? Is there another approach where I can share the text between these projects? Thanks for any suggestions. Trent - 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 -- View this message in context: http://www.nabble.com/How-can-I-share-text-resources-with-multiple-web-applications--tp22549375p22592795.html Sent from the Wicket - User 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: How can I share text resources with multiple web applications?
I'm definitely stretching this a little, but I also believe it to be true... Resource files are, in my mind, encapsulated by the package that they belong to. You should be able to *look* at a package and see a component with all its related resources. You should be able to right click on a component's folder and copy that folder and know that you have the whole package. I feel it's not intuitive for resources to be anywhere other than in the package they belong to. Anyway, putting them in a separate directory hierarchy (even if they wind up in the same Java packaging structure when you build the JAR) breaks this idea of encapsulation. In general, things should always be as private/local as possible. With resources, this is best accomplished by keeping them in the same folder. It seems that everyone who encounters Wicket for the first time goes through a period when they think this is wrongheaded... until they almost invariably change their minds about it. It definitely requires a small mind shift. luther.baker wrote: Hi Jonathan, Curious for your thoughts - how does separating html files into the resources directory break encapsulation? -Luther On Wed, Mar 18, 2009 at 10:19 PM, Jonathan Locke jonathan.lo...@gmail.comwrote: yes, but wicket takes a different view than maven on resources in general. they are always closest to the component they belong to. it's a form of encapsulation. so maybe it's wrong from maven's point of view, but putting them in src/main/resources would be wrong from wicket's point of view. the archetype should remain unchanged. Brill Pappin wrote: With Maven, non compiled files should be in src/main/resources The quickstart archetype actually does the *wrong* thing and puts them in with the java files. - Brill Pappin On 18-Mar-09, at 4:19 PM, Trent Larson wrote: Thanks for the suggestion. For posterity's sake: my problem was actually with the Maven 2 build, where it ignored the properties file (located in with the Java files) when it built the jar project. Trent On Mon, Mar 16, 2009 at 5:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: see iresourcesettings#addstringresourceloader() make one that loads your properties from some file you keep on the classpath -igor On Mon, Mar 16, 2009 at 4:00 PM, Trent Larson larsontr...@gmail.com wrote: I have 2 web applications, and I would like to allow them to share the same text files. The only way I've found is to make each WebApplication class extend a common ParentApplication class and make a ParentApplication.properties file to contain the common text; then I package the common ParentApplication class and properties in a separate jar project and include that in each of the web projects. This works great in Eclipse in an exploded environment; unfortunately, it looks like it does not work when I include the ParentApplication artifacts inside a separate jar. I get the following error: Caused by: java.util.MissingResourceException: Unable to find property: ' squeeze.presented.by' for component: [class=com.max.web.page.bizopp1Page] at org.apache.wicket.Localizer.getString(Localizer.java:269) . Is there any way to make this work? Is there another approach where I can share the text between these projects? Thanks for any suggestions. Trent - 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 -- View this message in context: http://www.nabble.com/How-can-I-share-text-resources-with-multiple-web-applications--tp22549375p22592795.html Sent from the Wicket - User 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 -- View this message in context: http://www.nabble.com/How-can-I-share-text-resources-with-multiple-web-applications--tp22549375p22594107.html Sent from the Wicket - User 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: [OT] Simple file repository?
and there's brix, a wicket cms framework written on top of jackrabbit John Armstrong-3 wrote: Jackrabbit is also great and does all of this and more with a nice friendly API wrapped around it. http://jackrabbit.apache.org/ And its an apache project.. I don't recommend rolling your own. Any Simple Content Repository soon gets User Permissions, Versioning, Search, Mixed Content and will eventually grow to consume all resources. John- On Sun, Feb 15, 2009 at 9:26 AM, Kaspar Fischer fisch...@inf.ethz.ch wrote: On 15.02.2009, at 18:00, francesco dicarlo wrote: Alfresco. And you have also lucene indexing. Just deploy the repository and upload files via webservice... That is certainly an option: Alfresco even offers Content Transformers; writing one to convert the movies would be easy. Anything more lightweight? Thanks, Kaspar - 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 -- View this message in context: http://www.nabble.com/-OT--Simple-file-repository--tp22024665p22027966.html Sent from the Wicket - User 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: What's your take on handling markup in properties, html, wicket
Ideally the markup should stay in the markup file and the text in that markup that needs to be localized would be localized via wicket:message and a properties file. In cases like below, you would break the text into properties-localized hunks and into panels with multiple markup localization files where markup is truly being localized (you have little other choice if the styling needs to be localized). How that's split up is up to you. In the example you gave, maybe: boldwicket:message key=welcome//boldbrbrwicket:messsage key=longText/ div wicket:id=bulletPanel/ welcome=Welcome to our company longText=Here is some long text BulletPanel.html_en wicket:panel ullisome [BOLD]text[/BOLD]/liliother text/li/ul /wicket:panel i would generally try to avoid putting much markup in properties files since that's a surprising use of properties files. Mathias P.W Nilsson wrote: Hi, Just wondering how this should be handled without DRY. In many scenarios we have multiple languages that should have the same markup but different text. This could be handled by using variation and put every language in an own html file like myWicketPage_style_en.html. However, this is not the optimal way and I don't think variation is made for this either. It would be very annoing having 14 different html files if we have 14 different languages that we should support. Sometimes the languages should look different ( not the same look. Different positioning of elements ) and here we could use variation. As far as I'm concerned this is not the right way of handling look and feel. Different css should be used instead and then place position, coloring of the markup in a css. The html file should be the same and the css should handle the layout. Take a look at http://www.csszengarden.com/ http://www.csszengarden.com/ Every time I'm dealing with multiple languages the user wants bold, italic, color in the text. Many times a list will appear just containing text. ( Nothing to do with extracting data from database and let wicket handle it ) This could be added in a properties file but then we would have bold tags, italic and style tags in the properties file. If something should change we need to go thru 14 properties files to change the markup in the properties. Let's say we have the following text in many different languages. Some markup is changed so you know what I mean. boldWelcome to our company/boldbrbrHere is some long text.ullisome [BOLD]text[/BOLD]/liliother text/li/ul Now imaging this text to be very long. Now, my question is this. How do you handle tagged markup for different languages without repeating markup tags. * Variation and the text in the html file. * different properties file with markup in it * Other technique? -- View this message in context: http://www.nabble.com/What%27s-your-take-on-handling-markup-in-properties%2C-html%2C-wicket-tp21995782p2245.html Sent from the Wicket - User 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: Feedback Next To Component
behaviors aren't really designed to work like components and render markup
like that, so it's a bit weird... what if you want to go extend or change
the markup for the feedback error? it's now embedded in a bunch of code.
walnutmon wrote:
In order to add feedback next to the component I used a behavior. I had
some code from Igor which got me on the right track, although I was unable
to actually get it to work the same way, I simplified it down to the
following code:
AbstractBehavior printMessagesNextToComponent = new AbstractBehavior()
{
@Override
public void onRendered(Component component)
{
super.onRendered(component);
FeedbackMessage message =
component.getFeedbackMessage();
if (message != null)
{
final Response out = component.getResponse();
out.write();
out.write(message.getMessage().toString());
out.write();
}
}
};
It almost seems too simple, I've tried it and with limited testing it
seems to work just fine, although there are some odd behaviors with
Ajax... does anyone have any comments, better solutions, or possible
breaking conditions that I should check out?
--
View this message in context:
http://www.nabble.com/Feedback-Next-To-Component-tp21959520p21964449.html
Sent from the Wicket - User 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 stuff core, archetypes?
couldn't sleep tonight, so i did a bit of work on it... http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata just a quick first sketch. thoughts? Jonathan Locke wrote: i don't have time to develop the metadata standard, but i could make time to review it. there are a few good things on that wiki page, but i'd say a bit more thinking could be applied (anyone want to help francisco?) and then get review from me and any other core devs who want to chime in. if wicket-user/wicket-dev then goes +1 on it, that's the standard. jon francisco treacy-2 wrote: your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. +1 the problem here though is that for things to work in parallel, well, by definition, you need more than 1 person doing stuff :) i guess the question is... who wants to move ahead with the component metadata standard while i develop stuff into wickethub? it would be also nice to have at least one example of wicket component with metadata to play with. for a list of things i plan to do, check the issues tab of the project home - and feel free to add. regards francisco On Wed, Jan 21, 2009 at 8:07 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: that's too bad. i was hoping nexus was a centralized index of all known public repos. your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. jon francisco treacy-2 wrote: hi jon, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub definitely my simplistic understanding was that nexus could search for jars with certain files in them. not unless you extend it it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us i have contacted them: see the thread http://nexus.sonatype.org/mailing-list-user-archives.html#nabble-f34835 basically it is technically possible to do what we need with nexus. the problem is that this wicket-aware extended nexus version has to be installed in every single repo we may want to synchronize with. so once we have done the coding we'll have to contact maven central (and other) repo owners. so it boils down to diplomacy rather than programming =) so: for now i will focus on submit jar url support that we will need anyway (for non-mavenized wicket components). at the moment this also will be useful for components in maven repos. and the day we manage to have an automatic 'discovery' process - people won't be required to submit wicket-enabled-repo urls anymore. how does that sound? francisco On Sat, Jan 17, 2009 at 10:02 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: i think maven searching is an ideal way to publish and discover wicket components at present. i never meant to imply that that should be the only way to do this or that the idea of a wicket component jar should be tied to something like a repository or a transport. i also don't think it should be tied to a specific repo of discovered meta information like wicket hub. that creates a centralized architecture and as much as i like the idea of wicket hub a lot, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub. for example, someone could gather wicket components for an IDE plugin, to store in some other type of repository than maven or to create an index for some future google search plugin. my simplistic understanding was that nexus could search for jars with certain files in them. all we need from nexus is the ability to get a list of jar artifacts which contain the file META-INF/wicket/components.xml because all such files will be wicket component jars (subject to downloading and parsing, of course). if nexus can't do that, i think that's a flaw in nexus and it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us. i think that a nexus driven wicket component repository would be beneficial advertising for the nexus project, and it should not be too hard to achieve. jon francisco treacy-2 wrote: you're certainly free to go in whatever direction you want, to be clear, i fully agree on the decentralized model for: - people and the development of this app, and data contributed by wicket users: this should be as democratic as possible - artifacts / components: there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) we should support any mavenized or non-mavenized artifacts, wherever those
Re: Wicket stuff core, archetypes?
using the maven deps is fine. the purpose i had in mind for the requirements and libraries nodes was just to enable display of the component's requirements on a page about the component... (whether it's built with maven or not). but using the maven deps would be more detailed and more consistent... and most wicket components will be mavenized. francisco treacy-2 wrote: coincidentally, i started working on that again and i was about to contact you to suggest a draft. my perspective are (for the moment) data that is to be mapped to fields currently supported in wicket hub. i put it in a jar metadata format. Site-URL: (maps to website url) License-Name: (maps to license) Wicket-Versions: (maps to supported wicket versions) Search-Keywords: (maps to topics) Publish-Date: (maps to latest publish date) Author: (maps to author) i uploaded a new version that has a minimal infrastructure (a running batch) to support pinging known components. basically it's yet to be put together (the download, unzip, parse metadata), but it's all there. regarding your metadata proposal, i think it's really fine. also, the xml format makes sense. however i'm not 100% convinced about requirements library name=wicket version=1.3/ library name=YUI version=4.0/ /requirements ... cause it's duplicating maven functionality, and i'm pretty sure maven handles it better. i know that our components are not necessarily mavenized, but even then we should pay particular attention to this one. as i said, i'm ready to get this done on my side - it would be nice if somebody else could work on a maven plugin or other post-install step to generate this metadata within jars. francisco -- http://wickethub.org On Mon, Feb 9, 2009 at 9:45 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: couldn't sleep tonight, so i did a bit of work on it... http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata just a quick first sketch. thoughts? Jonathan Locke wrote: i don't have time to develop the metadata standard, but i could make time to review it. there are a few good things on that wiki page, but i'd say a bit more thinking could be applied (anyone want to help francisco?) and then get review from me and any other core devs who want to chime in. if wicket-user/wicket-dev then goes +1 on it, that's the standard. jon francisco treacy-2 wrote: your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. +1 the problem here though is that for things to work in parallel, well, by definition, you need more than 1 person doing stuff :) i guess the question is... who wants to move ahead with the component metadata standard while i develop stuff into wickethub? it would be also nice to have at least one example of wicket component with metadata to play with. for a list of things i plan to do, check the issues tab of the project home - and feel free to add. regards francisco On Wed, Jan 21, 2009 at 8:07 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: that's too bad. i was hoping nexus was a centralized index of all known public repos. your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. jon francisco treacy-2 wrote: hi jon, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub definitely my simplistic understanding was that nexus could search for jars with certain files in them. not unless you extend it it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us i have contacted them: see the thread http://nexus.sonatype.org/mailing-list-user-archives.html#nabble-f34835 basically it is technically possible to do what we need with nexus. the problem is that this wicket-aware extended nexus version has to be installed in every single repo we may want to synchronize with. so once we have done the coding we'll have to contact maven central (and other) repo owners. so it boils down to diplomacy rather than programming =) so: for now i will focus on submit jar url support that we will need anyway (for non-mavenized wicket components). at the moment this also will be useful for components in maven repos. and the day we manage to have an automatic 'discovery' process - people won't be required to submit wicket-enabled-repo urls anymore. how does that sound? francisco On Sat, Jan 17, 2009 at 10:02 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: i think maven searching is an ideal way to publish and discover wicket components at present. i never meant to imply that that should be the only way to do this or that the idea
Re: Wicket stuff core, archetypes?
i don't have time to develop the metadata standard, but i could make time to review it. there are a few good things on that wiki page, but i'd say a bit more thinking could be applied (anyone want to help francisco?) and then get review from me and any other core devs who want to chime in. if wicket-user/wicket-dev then goes +1 on it, that's the standard. jon francisco treacy-2 wrote: your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. +1 the problem here though is that for things to work in parallel, well, by definition, you need more than 1 person doing stuff :) i guess the question is... who wants to move ahead with the component metadata standard while i develop stuff into wickethub? it would be also nice to have at least one example of wicket component with metadata to play with. for a list of things i plan to do, check the issues tab of the project home - and feel free to add. regards francisco On Wed, Jan 21, 2009 at 8:07 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: that's too bad. i was hoping nexus was a centralized index of all known public repos. your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. jon francisco treacy-2 wrote: hi jon, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub definitely my simplistic understanding was that nexus could search for jars with certain files in them. not unless you extend it it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us i have contacted them: see the thread http://nexus.sonatype.org/mailing-list-user-archives.html#nabble-f34835 basically it is technically possible to do what we need with nexus. the problem is that this wicket-aware extended nexus version has to be installed in every single repo we may want to synchronize with. so once we have done the coding we'll have to contact maven central (and other) repo owners. so it boils down to diplomacy rather than programming =) so: for now i will focus on submit jar url support that we will need anyway (for non-mavenized wicket components). at the moment this also will be useful for components in maven repos. and the day we manage to have an automatic 'discovery' process - people won't be required to submit wicket-enabled-repo urls anymore. how does that sound? francisco On Sat, Jan 17, 2009 at 10:02 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: i think maven searching is an ideal way to publish and discover wicket components at present. i never meant to imply that that should be the only way to do this or that the idea of a wicket component jar should be tied to something like a repository or a transport. i also don't think it should be tied to a specific repo of discovered meta information like wicket hub. that creates a centralized architecture and as much as i like the idea of wicket hub a lot, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub. for example, someone could gather wicket components for an IDE plugin, to store in some other type of repository than maven or to create an index for some future google search plugin. my simplistic understanding was that nexus could search for jars with certain files in them. all we need from nexus is the ability to get a list of jar artifacts which contain the file META-INF/wicket/components.xml because all such files will be wicket component jars (subject to downloading and parsing, of course). if nexus can't do that, i think that's a flaw in nexus and it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us. i think that a nexus driven wicket component repository would be beneficial advertising for the nexus project, and it should not be too hard to achieve. jon francisco treacy-2 wrote: you're certainly free to go in whatever direction you want, to be clear, i fully agree on the decentralized model for: - people and the development of this app, and data contributed by wicket users: this should be as democratic as possible - artifacts / components: there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) we should support any mavenized or non-mavenized artifacts, wherever those may live - you're right there (however i thought you said before you were interested at present only by components delivered by maven). parsing the metadata would be done after you download the artifact
Re: Wicket stuff core, archetypes?
that's too bad. i was hoping nexus was a centralized index of all known public repos. your plan makes sense to me. it seems like moving ahead with a wicket component metadata standard would be a good thing to do in parallel though. jon francisco treacy-2 wrote: hi jon, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub definitely my simplistic understanding was that nexus could search for jars with certain files in them. not unless you extend it it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us i have contacted them: see the thread http://nexus.sonatype.org/mailing-list-user-archives.html#nabble-f34835 basically it is technically possible to do what we need with nexus. the problem is that this wicket-aware extended nexus version has to be installed in every single repo we may want to synchronize with. so once we have done the coding we'll have to contact maven central (and other) repo owners. so it boils down to diplomacy rather than programming =) so: for now i will focus on submit jar url support that we will need anyway (for non-mavenized wicket components). at the moment this also will be useful for components in maven repos. and the day we manage to have an automatic 'discovery' process - people won't be required to submit wicket-enabled-repo urls anymore. how does that sound? francisco On Sat, Jan 17, 2009 at 10:02 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: i think maven searching is an ideal way to publish and discover wicket components at present. i never meant to imply that that should be the only way to do this or that the idea of a wicket component jar should be tied to something like a repository or a transport. i also don't think it should be tied to a specific repo of discovered meta information like wicket hub. that creates a centralized architecture and as much as i like the idea of wicket hub a lot, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub. for example, someone could gather wicket components for an IDE plugin, to store in some other type of repository than maven or to create an index for some future google search plugin. my simplistic understanding was that nexus could search for jars with certain files in them. all we need from nexus is the ability to get a list of jar artifacts which contain the file META-INF/wicket/components.xml because all such files will be wicket component jars (subject to downloading and parsing, of course). if nexus can't do that, i think that's a flaw in nexus and it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us. i think that a nexus driven wicket component repository would be beneficial advertising for the nexus project, and it should not be too hard to achieve. jon francisco treacy-2 wrote: you're certainly free to go in whatever direction you want, to be clear, i fully agree on the decentralized model for: - people and the development of this app, and data contributed by wicket users: this should be as democratic as possible - artifacts / components: there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) we should support any mavenized or non-mavenized artifacts, wherever those may live - you're right there (however i thought you said before you were interested at present only by components delivered by maven). parsing the metadata would be done after you download the artifact that you found. okay, fair enough. i have some doubts though: 1. in this scenario, downloading every artifact on earth just to open it and see if there's some wicket info inside is... impossible. 2. you just need to find the artifact with nexus. in your original blog post you say Basically, I'd like to see us crawl maven repos looking for JAR'ed Wicket components with a particular set of meta-data i don't see how nexus can help there. let's put another example: i create a mootools integration component, i mavenize it with package name com.mymootools.wicket and publish it in central repo. how does nexus help in finding that, if it doesn't know anything about META-INF/*.xml? ... *unless* you're planning people to submit their jar urls to wickethub. that would be a whole other story. but then again, nexus would be useless as we will already have the urls to components (no need to crawl or search - only to download the jar, open it up and update metadata in wickethub) for screenshots and the internal structure of the xml file, we shall see later, but i generally agree with you francisco
Re: Wicket presentation at Bulgarian JUG
very clever! Martin Grigorov-2 wrote: Hi all, I just uploaded the presentation that me and a colleague of mine did last Wednesday at Bulgarian Java user group. The event was quite a success. I hope we refactored some of the JSF supporters :-) The interesting thing about this presentation is that it was made with Wicket itself. Yes, the presentation is a web application that shows the Wicket concepts in action. You could see the presentation at http://marto.homeunix.org:8080/presentation And download the application from http://groups.google.com/group/bg-jug/web/20090114-bgjug-wicket.tgz Cheers martin-g P.S. As a source of inspiration we used all the presentations we found out there. Credits shared with their authors ! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Wicket-presentation-at-Bulgarian-JUG-tp21528817p21530966.html Sent from the Wicket - User 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 stuff core, archetypes?
you're certainly free to go in whatever direction you want, but i still like the idea of a fully decentralized model. there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) i also think the nexus indexer is enough. you just need to find the artifact with nexus. parsing the metadata would be done after you download the artifact that you found. at that point you can do anything with it, including extracting URLs or even embedded images (might be a nice option for screenshots). putting jar metadata in META-INF is much more appropriate in my mind because it's not maven-specific. the idea of a wicket component is not a maven-centric idea and a maven repository is just one way to publish a component. there are certainly going to be others. i do think that it might be a good idea to make the component metadata a separate xml file in a subfolder of META-INF instead of putting that info directly in the existing jar properties file. this is a lot more extensible and would allow multiple components in a single jar and would also uniquely identify a wicket component and be quite searchable with nexus by just looking for: META-INF/wicket/components.xml // define components in this jar (relative reference to metadata files, in this case: // component1/metadata.xml and component2/metadata.xml) META-INF/wicket/component1/metadata.xml // define metadata for first component META-INF/wicket/component2/metadata.xml // metadata for second component META-INF/wicket/component2/screenshots/1.jpg// embedded screenshots for second component META-INF/wicket/component2/screenshots/2.jpg at least as i understand it... if not, maybe nexus needs to be extended... francisco treacy-2 wrote: i don't completely agree: - to be searched by nexus, repo needs to be nexus-aware: i.e. nexus-maven-repository-index.properties and nexus-maven-repository-index.zip files need to be deployed to the /.index folder at maven repository root. we are mainly talking about wicketstuff projects currently hosted in a non-indexed (nothing at http://wicketstuff.org/maven/repository/.index/) community-owned repo. as far as i know, there are no wicket components in maven central repo. i insist, so long as wicketstuff is *our repo* we can do whatever we want with it. we can decide *not to ban* wickethub's crawler (our crawler). we still can use nexus though, but we're not forced to do so - moreover, no specific metadata indexed: Nexus indexer component provides an API to index Maven repository, merge and download index updates. It also provides an API to search through registered indexes using various search criteria, including: * Browse through repository indexes * Search jars by artifactId and groupId * Search jars by the packaging type (e.g. to find Maven plugins or Archetypes) * Search jars by sha1 (e.g. to identify arbitrary jars with actual Maven artifacts) * Search Maven artifacts/jar by class name (e.g. resolve classpath issues from build errors or class not found exceptions) ...knowing that we need to index specific metadata (http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata). by the way, i wouldn't store metadata under META-INF inside the jar; i would rather include it in the pom file. let's put an example, let's say we need to display up-to-date url of screenshots (or examples or whatever) Screenshots=http://mycomponents.com/slider/screenshots/1.jpg,http://mycomponents.com/slider/screenshots/2.jpg,... wickethub will somehow need to know about those urls. how could it grab that out of nexus? i had a look at their lucene api and i'm not aware of the aforementioned scenario being possible. wickethub's crawler is a custom solution. it has to be smarter in that regard - to be able to keep synchronized custom data *we* (but not everybody) will be using in maven artifacts. francisco On Thu, Jan 15, 2009 at 5:37 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: cool. this definitely looks like the right approach to me (assuming it indexes most of the big repos) jon Rodolfo Hansen wrote: Yes, you should use the nexus index for the repository http://nexus.sonatype.org/ The indexer api is pretty straight forward: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample you could search for artifacts with the appropriate metadata, or search inside the jars for some specific file / class (I think) On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy francisco.tre...@gmail.com wrote: wasn't this someone martijn? On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: For perusing the maven repository, one
Re: Wicket stuff core, archetypes?
by nexus, repo needs to be nexus-aware: i.e.
nexus-maven-repository-index.properties and
nexus-maven-repository-index.zip files need to be deployed to the
/.index folder at maven repository root.
we are mainly talking about wicketstuff projects currently hosted in a
non-indexed (nothing at
http://wicketstuff.org/maven/repository/.index/) community-owned repo.
as far as i know, there are no wicket components in maven central
repo.
i insist, so long as wicketstuff is *our repo* we can do whatever we
want with it. we can decide *not to ban* wickethub's crawler (our
crawler). we still can use nexus though, but we're not forced to do so
- moreover, no specific metadata indexed:
Nexus indexer component provides an API to index Maven repository,
merge and download index updates. It also provides an API to search
through registered indexes using various search criteria, including:
* Browse through repository indexes
* Search jars by artifactId and groupId
* Search jars by the packaging type (e.g. to find Maven plugins or
Archetypes)
* Search jars by sha1 (e.g. to identify arbitrary jars with actual
Maven artifacts)
* Search Maven artifacts/jar by class name (e.g. resolve classpath
issues from build errors or class not found exceptions)
...knowing that we need to index specific metadata
(http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata).
by the way, i wouldn't store metadata under META-INF inside the jar; i
would rather include it in the pom file.
let's put an example, let's say we need to display up-to-date url of
screenshots (or examples or whatever)
Screenshots=http://mycomponents.com/slider/screenshots/1.jpg,http://mycomponents.com/slider/screenshots/2.jpg,...
wickethub will somehow need to know about those urls. how could it
grab that out of nexus? i had a look at their lucene api and i'm not
aware of the aforementioned scenario being possible.
wickethub's crawler is a custom solution. it has to be smarter in that
regard - to be able to keep synchronized custom data *we* (but not
everybody) will be using in maven artifacts.
francisco
On Thu, Jan 15, 2009 at 5:37 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
cool. this definitely looks like the right approach to me (assuming it
indexes most of the big repos)
jon
Rodolfo Hansen wrote:
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
you could search for artifacts with the appropriate metadata, or
search
inside the jars for some specific file / class (I think)
On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy
francisco.tre...@gmail.com wrote:
wasn't this someone martijn?
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you banned.
i replied
martijn, banning policies are issued by repository owners. i don't
know which repo you're referring to as the maven repository.
central? apache?
i suggested setting up or reusing a repo that would be mainly for
wicket components, and owned by the project/ community. advantages:
- we simply don't ban wickethub's crawler
- we provide guidelines for wicket developers to easily publish
their
artifacts (and possibly check if metadata is present, etc)
as for the rest ('non-compliant'), that would be maintained manually
so no crawling involved.
francisco
On Wed, Jan 14, 2009 at 11:40 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
yeah, you really do need a maven expert's help i think. i was
chatting
with
someone about this and they said something to the effect of: oh,
god
no
don't crawl the maven repo. you'll get banned. so there's some
more
official way of doing this apparently.
francisco treacy-2 wrote:
here it is:
http://code.google.com/p/wickethub/ (source code for the
http://wickethub.org/ webapp)
a small piece of code (with not even unit tests so far) but
hopefully
the way to start addressing our ideas:
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
let me know if you're interested in contributing. i'd particularly
like to find a maven power-user(s) who'd like to help implementing
some of jon's automatic component repo thingy.
nino, what about the archetypes for wicketstuff?
francisco
On Sat, Dec 20, 2008 at 9:00 PM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Ahh, no did'nt follow the thing that far, will read up on it
now
Re: Wicket stuff core, archetypes?
cool. this definitely looks like the right approach to me (assuming it
indexes most of the big repos)
jon
Rodolfo Hansen wrote:
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
you could search for artifacts with the appropriate metadata, or search
inside the jars for some specific file / class (I think)
On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy
francisco.tre...@gmail.com wrote:
wasn't this someone martijn?
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you banned.
i replied
martijn, banning policies are issued by repository owners. i don't
know which repo you're referring to as the maven repository.
central? apache?
i suggested setting up or reusing a repo that would be mainly for
wicket components, and owned by the project/ community. advantages:
- we simply don't ban wickethub's crawler
- we provide guidelines for wicket developers to easily publish their
artifacts (and possibly check if metadata is present, etc)
as for the rest ('non-compliant'), that would be maintained manually
so no crawling involved.
francisco
On Wed, Jan 14, 2009 at 11:40 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
yeah, you really do need a maven expert's help i think. i was chatting
with
someone about this and they said something to the effect of: oh, god
no
don't crawl the maven repo. you'll get banned. so there's some more
official way of doing this apparently.
francisco treacy-2 wrote:
here it is:
http://code.google.com/p/wickethub/ (source code for the
http://wickethub.org/ webapp)
a small piece of code (with not even unit tests so far) but hopefully
the way to start addressing our ideas:
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
let me know if you're interested in contributing. i'd particularly
like to find a maven power-user(s) who'd like to help implementing
some of jon's automatic component repo thingy.
nino, what about the archetypes for wicketstuff?
francisco
On Sat, Dec 20, 2008 at 9:00 PM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Ahh, no did'nt follow the thing that far, will read up on it now..
I'll be looking forward to see some stuff in a couple of weeks :)
francisco treacy wrote:
hi nino,
have you seen jon's idea of automatic component , and/or
wickethub.org
thread? discussion went around providing to wicket component
developers some sort of archetype that can help to 'standardize'/
'give more structure' - also useful to perhaps crawl those
artifacts
(with metadata) and keep them up-to-date in a sort of registry. it
would be good to join efforts.
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
i'd really like to really tackle this one, once i'm back from
holidays
in about 2 weeks. gonna tidy up a bit and open source that wickethub
code.
cheers,
francisco
On Sat, Dec 20, 2008 at 9:22 AM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Hi
I were thinking that it would be nice to have archetypes for single
wicketstuff core project and one with a multi module (the stuff
project
and
a example one), I guess it would provide event more structure..
WDYT?
regards Nino
-
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
--
View this message in context:
http://www.nabble.com/Wicket-stuff-core%2C-archetypes--tp21102842p21466906.html
Sent from the Wicket - User mailing list archive
Re: Wicket stuff core, archetypes?
btw, maybe this maven artifact searching thing should be integrated somehow
with an existing wicket search engine?
http://www.google.com/coop/cse?cx=00079654818618231%3Aenjwek-gxxg
is that possible with google custom searches alastair?
Jonathan Locke wrote:
cool. this definitely looks like the right approach to me (assuming it
indexes most of the big repos)
jon
Rodolfo Hansen wrote:
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
you could search for artifacts with the appropriate metadata, or search
inside the jars for some specific file / class (I think)
On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy
francisco.tre...@gmail.com wrote:
wasn't this someone martijn?
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you banned.
i replied
martijn, banning policies are issued by repository owners. i don't
know which repo you're referring to as the maven repository.
central? apache?
i suggested setting up or reusing a repo that would be mainly for
wicket components, and owned by the project/ community. advantages:
- we simply don't ban wickethub's crawler
- we provide guidelines for wicket developers to easily publish their
artifacts (and possibly check if metadata is present, etc)
as for the rest ('non-compliant'), that would be maintained manually
so no crawling involved.
francisco
On Wed, Jan 14, 2009 at 11:40 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
yeah, you really do need a maven expert's help i think. i was chatting
with
someone about this and they said something to the effect of: oh, god
no
don't crawl the maven repo. you'll get banned. so there's some more
official way of doing this apparently.
francisco treacy-2 wrote:
here it is:
http://code.google.com/p/wickethub/ (source code for the
http://wickethub.org/ webapp)
a small piece of code (with not even unit tests so far) but hopefully
the way to start addressing our ideas:
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
let me know if you're interested in contributing. i'd particularly
like to find a maven power-user(s) who'd like to help implementing
some of jon's automatic component repo thingy.
nino, what about the archetypes for wicketstuff?
francisco
On Sat, Dec 20, 2008 at 9:00 PM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Ahh, no did'nt follow the thing that far, will read up on it now..
I'll be looking forward to see some stuff in a couple of weeks :)
francisco treacy wrote:
hi nino,
have you seen jon's idea of automatic component , and/or
wickethub.org
thread? discussion went around providing to wicket component
developers some sort of archetype that can help to 'standardize'/
'give more structure' - also useful to perhaps crawl those
artifacts
(with metadata) and keep them up-to-date in a sort of registry. it
would be good to join efforts.
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
i'd really like to really tackle this one, once i'm back from
holidays
in about 2 weeks. gonna tidy up a bit and open source that
wickethub
code.
cheers,
francisco
On Sat, Dec 20, 2008 at 9:22 AM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Hi
I were thinking that it would be nice to have archetypes for
single
wicketstuff core project and one with a multi module (the stuff
project
and
a example one), I guess it would provide event more structure..
WDYT?
regards Nino
-
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
Re: Why you should not override isVisible
I would be careful not to throw the baby out with the bath water here. The
design decision you're making is push versus pull and implementing isVisible
is often going to be a better design decision because it may be more clear
that visibility state stays consistent for a given problem. If the
performance actually shows up as a hotspot (don't prematurely optimize!),
you can always do some appropriate caching of the value and still have it
pulled.
Erik van Oosten wrote:
In the thread Where to process PageParameters I was requested to
explain why I think you should not override isVisible, but rather should
call setVisible in onBeforeRender (slide 100 in my presentation
http://www.grons.nl/~erik/pub/20081112%20Effective%20Wicket.pdf).
There are 2 reasons, but only the second one is really important.
-1- isVisible is called a lot. It is easily called ten times within 1
request
So if you have anything processor intensive going on, it will be a
performance hit. Just doing a simple expression is of course no problem.
(For fun, just set a breakpoint in something like
FeedbackPanel#isVisible and request a page that contains one.)
-2- isVisible can make your model be reloaded multiple times within 1
request
Consider the following case (pseudo code):
MyPanel(id, personId) {
super(id, new CompoundPropertyModel(new
LoadableDetachablePersonModel(personId)));
add( new Label(address) {
@Override
isVisible() {
return getDefaultModel() != null;
}
});
}
The label uses the property 'address' of a person to see if the label
should be visible. The person is retrieved by a LoadableDetachableModel
subclass (LDM) and then wrapped by a CompoundPropertyModel (CPM).
During the render phase, isVisible will delegate getting the address
property to the CPM and this model delegates it to the LDM. LDM will
load the person from the database only once (well until it is detached).
At the end of the render phase everything will be detached. But now
something weird happens. The problem is that isVisible is called during
the detach phase, on the label /after/ the CPM (and therefore also the
LDM) are detached. As isVisible retrieves the model from the CPM, and
therefore from the LDM, it will trigger a reload of the person inside
the LDM.
Now, as visibility is often (if not almost always) determined by a
business object (e.g. very often a LDM) I think it makes sense to avoid
having to think about the situation described above, and just avoid it
all together.
Note: I observed this behavior in Wicket 1.3 (1.3.3 I think). If it
works differently now, I would be very glad to withdraw this
recommendation.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Why-you-should-not-override-isVisible-tp21474995p21483816.html
Sent from the Wicket - User 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: Why you should not override isVisible
not sure. it /ought/ to make sense to cache during the render cycle. but i
have the eerie sense that this came up before, so maybe there's some reason
why it can't be cached? (although even if there are some odd cases where it
can't be, it seems like you could make a workaround for those cases ..)
Scott Swank wrote:
Is there a reason why the default behavior is not to cache the result
of isVisible()? Are there cases where the result of isVisible() is
expected to change over the course of rendering?
Would a JIRA w/ code be welcome, or is the current behavior required?
Scott
On Thu, Jan 15, 2009 at 10:23 AM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
I would be careful not to throw the baby out with the bath water here.
The
design decision you're making is push versus pull and implementing
isVisible
is often going to be a better design decision because it may be more
clear
that visibility state stays consistent for a given problem. If the
performance actually shows up as a hotspot (don't prematurely optimize!),
you can always do some appropriate caching of the value and still have it
pulled.
Erik van Oosten wrote:
In the thread Where to process PageParameters I was requested to
explain why I think you should not override isVisible, but rather should
call setVisible in onBeforeRender (slide 100 in my presentation
http://www.grons.nl/~erik/pub/20081112%20Effective%20Wicket.pdf).
There are 2 reasons, but only the second one is really important.
-1- isVisible is called a lot. It is easily called ten times within 1
request
So if you have anything processor intensive going on, it will be a
performance hit. Just doing a simple expression is of course no problem.
(For fun, just set a breakpoint in something like
FeedbackPanel#isVisible and request a page that contains one.)
-2- isVisible can make your model be reloaded multiple times within 1
request
Consider the following case (pseudo code):
MyPanel(id, personId) {
super(id, new CompoundPropertyModel(new
LoadableDetachablePersonModel(personId)));
add( new Label(address) {
@Override
isVisible() {
return getDefaultModel() != null;
}
});
}
The label uses the property 'address' of a person to see if the label
should be visible. The person is retrieved by a LoadableDetachableModel
subclass (LDM) and then wrapped by a CompoundPropertyModel (CPM).
During the render phase, isVisible will delegate getting the address
property to the CPM and this model delegates it to the LDM. LDM will
load the person from the database only once (well until it is detached).
At the end of the render phase everything will be detached. But now
something weird happens. The problem is that isVisible is called during
the detach phase, on the label /after/ the CPM (and therefore also the
LDM) are detached. As isVisible retrieves the model from the CPM, and
therefore from the LDM, it will trigger a reload of the person inside
the LDM.
Now, as visibility is often (if not almost always) determined by a
business object (e.g. very often a LDM) I think it makes sense to avoid
having to think about the situation described above, and just avoid it
all together.
Note: I observed this behavior in Wicket 1.3 (1.3.3 I think). If it
works differently now, I would be very glad to withdraw this
recommendation.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Why-you-should-not-override-isVisible-tp21474995p21483816.html
Sent from the Wicket - User 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
--
View this message in context:
http://www.nabble.com/Why-you-should-not-override-isVisible-tp21474995p21484456.html
Sent from the Wicket - User 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: Why you should not override isVisible
well yes, it might break existing behavior, that's why i suggested having a
workaround for that. although i would think that well-designed isVisible
methods shouldn't generally have this problem.
you could always work it the other way and have no caching by default but
allow people who know what they're doing to enable it for an application
with something like
IRequestCycleSettings#setCacheComponentVisibility(boolean).
Martin Makundi wrote:
Well... I would not build in the cache because different components
could interact in a way that if someone prematurely calls the
isVisible method, it freezes in the wrong state. It is known, that the
isVisible is called multiple times for various reasons.
**
Martin
2009/1/15 Jonathan Locke jonathan.lo...@gmail.com:
not sure. it /ought/ to make sense to cache during the render cycle. but
i
have the eerie sense that this came up before, so maybe there's some
reason
why it can't be cached? (although even if there are some odd cases where
it
can't be, it seems like you could make a workaround for those cases ..)
Scott Swank wrote:
Is there a reason why the default behavior is not to cache the result
of isVisible()? Are there cases where the result of isVisible() is
expected to change over the course of rendering?
Would a JIRA w/ code be welcome, or is the current behavior required?
Scott
On Thu, Jan 15, 2009 at 10:23 AM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
I would be careful not to throw the baby out with the bath water here.
The
design decision you're making is push versus pull and implementing
isVisible
is often going to be a better design decision because it may be more
clear
that visibility state stays consistent for a given problem. If the
performance actually shows up as a hotspot (don't prematurely
optimize!),
you can always do some appropriate caching of the value and still have
it
pulled.
Erik van Oosten wrote:
In the thread Where to process PageParameters I was requested to
explain why I think you should not override isVisible, but rather
should
call setVisible in onBeforeRender (slide 100 in my presentation
http://www.grons.nl/~erik/pub/20081112%20Effective%20Wicket.pdf).
There are 2 reasons, but only the second one is really important.
-1- isVisible is called a lot. It is easily called ten times within 1
request
So if you have anything processor intensive going on, it will be a
performance hit. Just doing a simple expression is of course no
problem.
(For fun, just set a breakpoint in something like
FeedbackPanel#isVisible and request a page that contains one.)
-2- isVisible can make your model be reloaded multiple times within 1
request
Consider the following case (pseudo code):
MyPanel(id, personId) {
super(id, new CompoundPropertyModel(new
LoadableDetachablePersonModel(personId)));
add( new Label(address) {
@Override
isVisible() {
return getDefaultModel() != null;
}
});
}
The label uses the property 'address' of a person to see if the label
should be visible. The person is retrieved by a
LoadableDetachableModel
subclass (LDM) and then wrapped by a CompoundPropertyModel (CPM).
During the render phase, isVisible will delegate getting the address
property to the CPM and this model delegates it to the LDM. LDM will
load the person from the database only once (well until it is
detached).
At the end of the render phase everything will be detached. But now
something weird happens. The problem is that isVisible is called
during
the detach phase, on the label /after/ the CPM (and therefore also the
LDM) are detached. As isVisible retrieves the model from the CPM, and
therefore from the LDM, it will trigger a reload of the person inside
the LDM.
Now, as visibility is often (if not almost always) determined by a
business object (e.g. very often a LDM) I think it makes sense to
avoid
having to think about the situation described above, and just avoid it
all together.
Note: I observed this behavior in Wicket 1.3 (1.3.3 I think). If it
works differently now, I would be very glad to withdraw this
recommendation.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Why-you-should-not-override-isVisible-tp21474995p21483816.html
Sent from the Wicket - User 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
Re: Why you should not override isVisible
yeah, for full flexibility, you might just link a method in Component to a
default in IRequestCycleSettings:
boolean getCacheComponentVisibility() { return
getApplication().getRequestCycleSettings().getCacheComponentVisibility(); }
then you can set a default and override for any individual component (or
page).
Martin Makundi wrote:
you could always work it the other way and have no caching by default but
allow people who know what they're doing to enable it for an application
with something like
IRequestCycleSettings#setCacheComponentVisibility(boolean).
This sounds more robust, so long as it can be controlled on a
per-request basis (i.e., you can configure it for a specific page and
state).
And don't forget about isEnabled too though it is more rare ;)
**
Martin
Martin Makundi wrote:
Well... I would not build in the cache because different components
could interact in a way that if someone prematurely calls the
isVisible method, it freezes in the wrong state. It is known, that the
isVisible is called multiple times for various reasons.
**
Martin
2009/1/15 Jonathan Locke jonathan.lo...@gmail.com:
not sure. it /ought/ to make sense to cache during the render cycle.
but
i
have the eerie sense that this came up before, so maybe there's some
reason
why it can't be cached? (although even if there are some odd cases
where
it
can't be, it seems like you could make a workaround for those cases ..)
Scott Swank wrote:
Is there a reason why the default behavior is not to cache the result
of isVisible()? Are there cases where the result of isVisible() is
expected to change over the course of rendering?
Would a JIRA w/ code be welcome, or is the current behavior required?
Scott
On Thu, Jan 15, 2009 at 10:23 AM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
I would be careful not to throw the baby out with the bath water
here.
The
design decision you're making is push versus pull and implementing
isVisible
is often going to be a better design decision because it may be more
clear
that visibility state stays consistent for a given problem. If the
performance actually shows up as a hotspot (don't prematurely
optimize!),
you can always do some appropriate caching of the value and still
have
it
pulled.
Erik van Oosten wrote:
In the thread Where to process PageParameters I was requested to
explain why I think you should not override isVisible, but rather
should
call setVisible in onBeforeRender (slide 100 in my presentation
http://www.grons.nl/~erik/pub/20081112%20Effective%20Wicket.pdf).
There are 2 reasons, but only the second one is really important.
-1- isVisible is called a lot. It is easily called ten times within
1
request
So if you have anything processor intensive going on, it will be a
performance hit. Just doing a simple expression is of course no
problem.
(For fun, just set a breakpoint in something like
FeedbackPanel#isVisible and request a page that contains one.)
-2- isVisible can make your model be reloaded multiple times within
1
request
Consider the following case (pseudo code):
MyPanel(id, personId) {
super(id, new CompoundPropertyModel(new
LoadableDetachablePersonModel(personId)));
add( new Label(address) {
@Override
isVisible() {
return getDefaultModel() != null;
}
});
}
The label uses the property 'address' of a person to see if the
label
should be visible. The person is retrieved by a
LoadableDetachableModel
subclass (LDM) and then wrapped by a CompoundPropertyModel (CPM).
During the render phase, isVisible will delegate getting the address
property to the CPM and this model delegates it to the LDM. LDM will
load the person from the database only once (well until it is
detached).
At the end of the render phase everything will be detached. But now
something weird happens. The problem is that isVisible is called
during
the detach phase, on the label /after/ the CPM (and therefore also
the
LDM) are detached. As isVisible retrieves the model from the CPM,
and
therefore from the LDM, it will trigger a reload of the person
inside
the LDM.
Now, as visibility is often (if not almost always) determined by a
business object (e.g. very often a LDM) I think it makes sense to
avoid
having to think about the situation described above, and just avoid
it
all together.
Note: I observed this behavior in Wicket 1.3 (1.3.3 I think). If it
works differently now, I would be very glad to withdraw this
recommendation.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Why-you-should-not-override-isVisible-tp21474995p21483816
