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
wrote:
> On Fri, Oct 7, 2016 at 10:43 PM, Jonathan Locke
> 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"
> > 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
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" 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
> > 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" >
> > > > 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
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
> 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"
> > 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&wicket-ajax-baseurl=view%3F0&wicket-app-name=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
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
> 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"
>>> 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
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
> 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"
>>> 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
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 > wrote:
>
>> What exactly is the problem?
>> Which impl of Wicket WebSockets do you use?
>>
>> On Oct 5, 2016 9:56 PM, "Jonathan Locke"
>> 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 wrote: > What exactly is the problem? > Which impl of Wicket WebSockets do you use? > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" 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 wrote: > What exactly is the problem? > Which impl of Wicket WebSockets do you use? > > On Oct 5, 2016 9:56 PM, "Jonathan Locke" 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 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 : >>> >>> 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
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
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
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
page expire / ajax error
I have two wicket applications running on the same box (my laptop, for example) with one on port 8880 and one on port 8881. Each application does ajax-self-updating. Now, if I start the first application, all is well and will stay well forever as far as I can tell. But the exact moment i start up the second application, the first application suddenly gets either a page expired error (under wicket 1.4) or an error regarding behaviors (under wicket 1.5). I've tried this over and over and it's not a fluke. Anyone have any idea what's going on? My best guess is that somehow Tomcat is misconfigured (I'm starting it embedded)? But how might that be? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/page-expire-ajax-error-tp3915594p3915594.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 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
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
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: 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 ".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
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: 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: ERROR: exceded the 65,535 byte limit Please Help me!
You certainly do need to learn something about Java. But while you're doing that, you also need to start learning how to think about coding. If you do it by trial and error like this, it will take you years to learn something you could learn in months. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ERROR-exceded-the-65-535-byte-limit-Please-Help-me-tp3041743p3041891.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: ERROR: exceded the 65,535 byte limit Please Help me!
In the end, the code above is some pretty horrific and very optional suffering. When I look at that code, I basically see a dislocated shoulder. A novice went to the gym and started trying to move the weights instead of exercise the muscle. Thinking in Java is a good book. No doubt about it. But to my taste, there is still a lot of "trying to move the weights" to it. There's too much about Java and not enough about thinking for a beginner. In the end, you don't need a book at all so much as you need to stop and REALLY, TRULY THINK about what you are doing and why. In my experience, very, very few people do this with any real regularity. In fact, it's not really a beginner problem. Even most of the very experience programmers I know don't do nearly enough of this. Particularly if what they are doing seems to be "working for them." But in the end, repeating what works is like moving the weights at the gym -- it's a trap and a good way to get injured -- and the only way out of that trap is to stay focused on incremental improvement of process. The master craftsman cares not so much about what is accomplished, but HOW it is accomplished. Truth is, you don't need my book. You can learn everything you need to know by reading this post a few times and taking it to heart. If you do, the shift in mind-set will be enormous. You will get stronger, much, much faster and you won't tear a rotator cuff like the guy above. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ERROR-exceded-the-65-535-byte-limit-Please-Help-me-tp3041743p3041888.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: ERROR: exceded the 65,535 byte limit Please Help me!
*bows* -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ERROR-exceded-the-65-535-byte-limit-Please-Help-me-tp3041743p3041843.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: ERROR: exceded the 65,535 byte limit Please Help me!
Yes. Learning Java better would certainly help, but to me there's an even deeper problem because what we're looking at is result-oriented coding... and result-oriented coding is what gets you into this sort of mess. The way out of that trap in general is to start working on and thinking about *process*. http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA Jon -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ERROR-exceded-the-65-535-byte-limit-Please-Help-me-tp3041743p3041802.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
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
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
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
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
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
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: 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
Yes. The other 90% is just filler. On Oct 2, 2010, at 7:42 AM, "James Carman [via Apache Wicket]" 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 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
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 > 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: Templates in Wicket
we did almost exactly the same thing at thoof. although occasionally you'll get a designer stuck on a build problem or something, it works really well. definitely the best approach in my mind. igor.vaynberg wrote: > > so you are giving designers markup from a wicket app? why not just let > them run the app, that way they can go in and do things themselves? > > in my company out developers checkout the code and run mvn jetty to > get the app up and running with markup reloading, then they go in with > textmate or coda and tweak the markup. > > -igor > > On Fri, Jan 15, 2010 at 8:00 AM, Marek Šabo wrote: >> Hi everyone, >> >> I would like to know if someone can share their experience with graphical >> templates under wicket. It's easy to provide markup code for designers, >> they >> just need to preserve hierarchy of wicket elements, right? But how do you >> cope with things like attribute modifier inside application and dynamic >> loading of other css files? Or what is the most common approach to this >> kind >> of thing? >> >> Regards, >> >> Marek >> >> - >> 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/Templates-in-Wicket-tp27179274p27179469.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 >>> 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 >>>&g
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 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
honestly, your response is too thoughtful. these pointy haired bosses are self-serving. they don't care about training costs or developer pain and they don't really care if their org runs efficiently. what they care about is that if there is a failure, their choice didn't cause it. which is why the old saying goes "nobody ever got fired for buying IBM." same seems to go for struts. an idiotic technology choice, but you won't get fired for making the same idiotic choice everyone else is making. Loritsch, Berin C. wrote: > > "But why choose an inferior technology just because of its adoption > numbers?" > > The pointy haired bosses that do this believe in their heart of hearts > that if you choose the same technology everyone else is using that they > can turn thinking developers for mindless drones. It has more to do > with avoiding training costs and rational thought, and more to do with > trying to turn software development into an assembly line process. > Reality never fits this mold, but it doesn't stop the pointy haired boss > from trying. In this respect they are eternal optimists. > > -Original Message- > From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com] > Sent: Friday, January 08, 2010 4:09 AM > To: users@wicket.apache.org > Subject: Re: Help with Wicket Adoption Numbers > > Hi, > > We also had the same consideration when we chose Wicket. But why choose > an > inferior technology just because of it's Adoption Numbers? Also, Wicket > is > becoming more and more popular as people see the light :) > > Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket): > http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1 > > We have a couple of hundred customers and so far the feedback is great > both from our Developers and our Software Architects. Customers like > that > the GUIs are faster due to the simplicity of Ajax Adoption in Wicket. > > I also know that several large privately held companies in Sweden are > using Wicket, as well as large Government Agencies (e.g. the Swedish > Immigration Office). > > > Sincerely yours > Leo Erlandsson > > > - > 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-tp27069702p27082559.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 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
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 > 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: 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: 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 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 :
>> 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 :
>>> 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();
>>>
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 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
> wrote:
>
>> 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
>> 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:*
>> >
>> >
>> >> > href="style/default/main.css"/>
>> >
>> >
>> > *MARKUP OUT:*
>> >
>> >
>> >
>> >
>> >
>> > *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
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 Locke > 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 Locke >>> 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
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 Locke > 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
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
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 > wrote: > >> >> >> I am currently trying to debug a markup handling problem where Wicket is >> complaining that it "Failed to handle: > 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?
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
>> 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: 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
>> 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?
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
>> 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: 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 > 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 : >> 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
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 : >> 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
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: 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: 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: 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: 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
>>
>>
>>
>>
>> # [project]
>>
>>
>>
>>
>>
>> *.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: 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
>
>
>
>
> # [project]
>
>
>
>
>
> *.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: 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=safari&rls=en-us&oe=UTF-8&um=1&ie=UTF-8&cid=0,0,16474381925794425644&fb=1&split=1&dq=moevenpick+hotel+amsterdam+piet+heinkade&daddr=Piet+Heinkade+11,+1019+BR+Amsterdam,+Netherlands&geocode=10995011565374881002,52.378048,4.914107&ei=e5fISb-PIsS4-Qb1_tGZAw&sa=X&oi=local_result&resnum=1&ct=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?
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 > wrote: > >> >> >> 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 >> > >> >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 >> >>> 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 >> >>>> >> >>> >> >
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 > >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 >>> 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: WML + Wicket experiences?
it's totally possible. did it at a company last year (but that's proprietary, of course). Martin Makundi wrote: > > Hi! > > There has been some discussion in the past about using Wicket for > rendering WML pages: > http://cwiki.apache.org/WICKET/mobile-devices.html > > Is there any such wml+wicket boilerplate/quickstart code available out > there or would someone like to post their experiences? > > ** > 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/WML-%2B-Wicket-experiences--tp22076991p22081338.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 > 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: welcome=Welcome to our company longText=Here is some long text BulletPanel.html_en some [BOLD]text[/BOLD]other text 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. > > Welcome to our companyHere is some long > text.some [BOLD]text[/BOLD]other text > > 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?
i like it. but don't you think that components should be able to specify either internal or external resources via the URL? if someone wants to embed the example/demo, snapshots and source code in the component jar, it seems like they should be able to do it (ala my example xml on the wiki). it would make the component more foolproof in terms of installing, playing with it etc. also, if the examples are typically embedded, the user can do java -jar to run the example like a program with no need to do any kind of installation... francisco treacy-2 wrote: > > i completely agree with you in that "Wicket component jars should be > fully self-describing, so i think wicket meta information has to be > independent of any external technology such as maven or osgi". > > however the only practical way nowadays to universally identify a > component is using its maven coordinates. > > so, to get started, we could just impose specifying deps in > wicket-components.xml as this (typical maven pom snippet): > > > org.apache.wicket > wicket > 1.4 > > > note that this doesn't restrain you from publishing your non-mavenized > jar. you will only have to manually set them in that case (assuming > some day we create a maven post-install to generate > wicket-components.xml for mavenized ones). > > also, the sources and the example jar should be pointing to external > resources. for instance in wicketstuff examples are not packaged with > the main component. > > francisco > > > > On Mon, Feb 9, 2009 at 4:06 PM, Jonathan Locke > wrote: >> >> >> 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 >>> >>> >>> >>> >>> >>> >>> ... 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 >>> >>> 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. >
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 > > > > > > > ... 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 > 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 >>>> 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 >
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 >> 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 >>>> 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 >>>>> compone
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 > 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 >>> 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 >>>> &q
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 > 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 t
