date:20070123


you can't just write to something in the constructor (thats in the
event/request phase)

make a RequestTarget that outputs that what you want and set that request
target as the response request target
on the request cycle

RequestCycle.get().setRequestTarget(new IRequestTarget()
{
  void respond(RequestCycle requestCycle)
  {
   Response rep = requestCycle.getResponse();
   rep.write(yourxml);
  }
});

johan

On 1/23/07, Daniel Nüst [EMAIL PROTECTED] wrote:


Hi Igor!

Igor Vaynberg schrieb:
 looks like you are trying to output your xml too late in the game
 (wicket has already written something to the request).
I would rather guess it seems the other way around (and I will try to
explain the situation a bit better):

* If I use res.write( xmlout.outputString( doc ) );, I do not get the
exeption, but the response is not a xml file, but a xml+html document:

?xml version=1.0 encoding=UTF-8?
newsList xlmns=http:// ... /newsList
html
head
meta http-equiv=Content-Type content=text/html; charset=Cp1252/


* If I use xmlout.output(doc, res.getOutputStream() );, I have an
exception (whole trace):

java.lang.IllegalStateException: getOutputStream() has already been
called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java
:599)
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java
:195)
at wicket.protocol.http.WebResponse.write(WebResponse.java:315)
at
wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java
:75)
at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java
:229)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at

org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)

To me it looks as if I wrote my xml file and wicket wants to write the
html code just behind it (just as it does when i use Response.write() ),
but it cannot because I already called getOutputStream().

I create the xml file on runtime and do not have a empty one in the same
directory as suggested in the rss examples, but I see not reason that is
the problem.

 what triggers that code?
The constructor:

public RequestXML() {
WebRequest req = (WebRequest) getRequest();
WebResponse res = (WebResponse) getResponse();

parametersToResponse(req.getParameterMap(), res);
} catch (IOException e) {
e.printStackTrace();
}
}

I want to use that page to request data out of a Firefox extension.
I appreciate every idea.

Regards
Daniel



 -igor


 On 1/22/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Hi!

 I want to load an XML-file from a wicket page concerning the html
page
 parameters with javascript. The javascript part (load and parse xml)
 works fine and also the generated xml file is okay.

 I just always get an

 java.lang.IllegalStateException: getOutputStream() has already been
 called for this response
 at
 org.apache.catalina.connector.Response.getWriter(Response.java:599)
 at
 org.apache.catalina.connector.ResponseFacade.getWriter
 (ResponseFacade.java:195)
 at wicket.protocol.http.WebResponse.write(WebResponse.java
:315)
 at
 wicket.protocol.http.BufferedWebResponse.close(
BufferedWebResponse.java:75)
 at wicket.protocol.http.WicketServlet.doGet
 (WicketServlet.java:229)
 [...]


 I did some research on this problem and found some workarounds for
jsp.
 I also tried different combinations of Streams and Writers. Alsways
that
 exception.

 The code:

 private void

Re: [Wicket-user] VOTE: IModel and 'model object' name change


We already have a getValue on formcomponent
that is the input value from the request or the model object as a string
(just the latest value)
So then that also has to be renamed. (and relearned)

I think getModelObject() is just what it says. (besides the getModel() call
we also have!)
else it should be getModelValue() not just getValue()

So i am -1 for changing getModelObject to getValue() that isn't descriptive
enough for me and will
collide with what we already have and that will result in even more renames.

I dont care to much +0 about changing the IModel interface itself (it
already has changed a bit because of the lost param in 2.0)
But i don't know if that really has much value.

johan




On 1/23/07, Jonathan Locke [EMAIL PROTECTED] wrote:




i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):

public interface IModelV extends IDetachable
{
  V getValue();
  void setValue(V value);
}

we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred).  there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.

i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things.  in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).

i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen.  but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.


Jonathan Locke wrote:


 We did already break the model contract with 1.2/1.3... would
 get/setObject-get/setValue be a huge hassle?  Or am I spacing something
 here?


 Jonathan Locke wrote:


 Made a few more changes.  I think it's getting shorter/better.

 My one regret looking at this documentation is that I wish
 IModel.get/setObject were actually IModel.get/setValue.  Or was there
 some crazy reason we didn't do this?  It would be much easier and more
 natural to talk about a model's value this way...


 Jonathan Locke wrote:


 Nice work.  I made a few small changes and rephrased the first
paragraph
 to be even more specific.  Maybe it could be tweaked a little more,
but
 I think this sums it up better now:

 In Wicket, a model holds a value for a component to display and/or
 edit. How exactly this value is held is determined by a given model's
 implementation of the wicket.model.IModel interface. This interface
 decouples a component from the data which forms its value. This in
turn
 decouples the whole Wicket framework from any and all details of model
 storage, such as the details of a given persistence technology. As far
 as Wicket itself is concerned, a model is anything that implements the
 IModel interface, no matter how it might do that.

 It does feel like this is the best place to show the IModel interface
 since readers will be wondering what it looks like already.  It sounds
 scarier than it is, so why delay?


 Loren Rosen wrote:

 I've saved my rewritten version. (See

http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
 Comments by everyone from experts to complete newbies
 are most welcome. Doubtless there are things that are confusing or
 flat-out wrong.

 In addition to rephrasing or rewriting a lot of material, and adding
a
 few things, I
 excised some details I thought would be distracting for a beginner.
 Some of this
 material is, I think, still useful, perhaps in a slightly more
advanced
 More about
 Models page.


 igor.vaynberg wrote:

 go ahead and edit the page...the wiki is versioned i think so we can
 always
 roll back.

 when you are done with the majority let us know and we will review
the
 changes.

 -igor


 On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:


 When I first started using Wicket I found the information on models
a
 little
 hard to follow. So now I'd like to revise the Working with Wicket
 models
 wiki page
 (

http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
 )
 to improve this. I'd be happy to outline what I think should be
 improved
 (though this is a little hard to do in detail short of simply
 annotating
 the
 page) or I can just plunge ahead and draft a revised page. If I do
 the
 latter I could potentially post it somewhere else for comment
instead
 of
 directly replacing the existing page on the wiki. Perhaps we need a
 'in
 draft' part of the wiki for working on long pages like this one.

 Actually, another

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Nino Wael

Im -1. 

As most of my models holds objects and not value, I've had no problem 
understanding this part of the IModel.

I must admit that I may be blind to this because im used to the current naming, 
and have been working with it for so long. I guess the new users would be the 
ones best to tell us which would be better.

But I do think that getModelObject, is very descriptive. 

It tells that you want to get the object that the model hold. getValue just 
tells that you want to get a value, which value is it that you are getting is 
an integer or what?

Regards Nino

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke
Sent: 23. januar 2007 07:51
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] VOTE: IModel and 'model object' name change



i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):

public interface IModelV extends IDetachable
{
  V getValue();
  void setValue(V value);
}

we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred).  there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.

i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things.  in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).

i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen.  but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.


Jonathan Locke wrote:
 
 
 We did already break the model contract with 1.2/1.3... would
 get/setObject-get/setValue be a huge hassle?  Or am I spacing something
 here?
 
 
 Jonathan Locke wrote:
 
 
 Made a few more changes.  I think it's getting shorter/better.  
 
 My one regret looking at this documentation is that I wish
 IModel.get/setObject were actually IModel.get/setValue.  Or was there
 some crazy reason we didn't do this?  It would be much easier and more
 natural to talk about a model's value this way... 
 
 
 Jonathan Locke wrote:
 
 
 Nice work.  I made a few small changes and rephrased the first paragraph
 to be even more specific.  Maybe it could be tweaked a little more, but
 I think this sums it up better now:
 
 In Wicket, a model holds a value for a component to display and/or
 edit. How exactly this value is held is determined by a given model's
 implementation of the wicket.model.IModel interface. This interface
 decouples a component from the data which forms its value. This in turn
 decouples the whole Wicket framework from any and all details of model
 storage, such as the details of a given persistence technology. As far
 as Wicket itself is concerned, a model is anything that implements the
 IModel interface, no matter how it might do that.
 
 It does feel like this is the best place to show the IModel interface
 since readers will be wondering what it looks like already.  It sounds
 scarier than it is, so why delay?
 
 
 Loren Rosen wrote:
 
 I've saved my rewritten version. (See
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
 Comments by everyone from experts to complete newbies
 are most welcome. Doubtless there are things that are confusing or
 flat-out wrong.
 
 In addition to rephrasing or rewriting a lot of material, and adding a
 few things, I
 excised some details I thought would be distracting for a beginner.
 Some of this
 material is, I think, still useful, perhaps in a slightly more advanced
 More about
 Models page.
 
 
 igor.vaynberg wrote:
 
 go ahead and edit the page...the wiki is versioned i think so we can
 always
 roll back.
 
 when you are done with the majority let us know and we will review the
 changes.
 
 -igor
 
 
 On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:


 When I first started using Wicket I found the information on models a
 little
 hard to follow. So now I'd like to revise the Working with Wicket
 models
 wiki page
 (
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
 )
 to improve this. I'd be happy to outline what I think should be
 improved
 (though this is a little hard to do in detail short of simply
 annotating
 the
 page) or I can just plunge ahead and draft a revised page. If I do
 the
 latter I could potentially post it somewhere else for comment instead
 of
 directly replacing the existing page on the wiki. Perhaps we need a
 'in
 draft' part

Re: [Wicket-user] Exception on WebResponse Outputstream

2007-01-23 Thread Daniel Nüst

Thank you very much, Johan!

I wrote my own XMLRequestTarget around your code and now it works.

Daniel

Johan Compagner schrieb:
 you can't just write to something in the constructor (thats in the
 event/request phase)
 
 make a RequestTarget that outputs that what you want and set that
 request target as the response request target
 on the request cycle
 
 RequestCycle.get().setRequestTarget(new IRequestTarget()
 {
void respond(RequestCycle requestCycle)
{
 Response rep = requestCycle.getResponse();
 rep.write(yourxml);
}
 });
 
 johan
 
 On 1/23/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
 
 Hi Igor!
 
 Igor Vaynberg schrieb:
  looks like you are trying to output your xml too late in the game
  (wicket has already written something to the request).
 I would rather guess it seems the other way around (and I will try to
 explain the situation a bit better):
 
 * If I use res.write( xmlout.outputString( doc ) );, I do not get the
 exeption, but the response is not a xml file, but a xml+html document:
 
 ?xml version= 1.0 encoding=UTF-8?
 newsList xlmns=http:// ... /newsList
 html
 head
 meta http-equiv=Content-Type content=text/html; charset=Cp1252/
 
 
 * If I use xmlout.output(doc, res.getOutputStream() );, I have an
 exception (whole trace):
 
 java.lang.IllegalStateException: getOutputStream() has already been
 called for this response
 at
 org.apache.catalina.connector.Response.getWriter(Response.java:599)
 at
 
 org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:195)
 at wicket.protocol.http.WebResponse.write(WebResponse.java :315)
 at
 
 wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:75)
 at
 wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:229)
 at javax.servlet.http.HttpServlet.service (HttpServlet.java:689)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at
 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at
 org.apache.catalina.core.StandardContextValve.invoke
 (StandardContextValve.java:178)
 at
 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at
 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 
 at
 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at
 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at
 org.apache.coyote.http11.Http11Processor.process
 (Http11Processor.java:869)
 at
 
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
 (PoolTcpEndpoint.java:527)
 at
 
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
 at
 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java
 :684)
 at java.lang.Thread.run(Unknown Source)
 
 To me it looks as if I wrote my xml file and wicket wants to write the
 html code just behind it (just as it does when i use Response.write() ),
 but it cannot because I already called getOutputStream().
 
 I create the xml file on runtime and do not have a empty one in the same
 directory as suggested in the rss examples, but I see not reason that is
 the problem.
 
  what triggers that code?
 The constructor:
 
 public RequestXML() {
 WebRequest req = (WebRequest) getRequest();
 WebResponse res = (WebResponse) getResponse();
 
 parametersToResponse(req.getParameterMap(), res);
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
 
 I want to use that page to request data out of a Firefox extension.
 I appreciate every idea.
 
 Regards
 Daniel
 
 
 
  -igor
 
 
  On 1/22/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]  wrote:
 
  Hi!
 
  I want to load an XML-file from a wicket page concerning the
 html page
  parameters with javascript. The javascript part (load and
 parse xml)
  works fine and also the generated xml file is okay.
 
  I just always get an

Re: [Wicket-user] Exception on WebResponse Outputstream

2007-01-23 Thread Daniel Nüst

Hi Igor!

Igor Vaynberg schrieb:
 looks like you are trying to output your xml too late in the game
 (wicket has already written something to the request). 
I would rather guess it seems the other way around (and I will try to
explain the situation a bit better):

* If I use res.write( xmlout.outputString( doc ) );, I do not get the
exeption, but the response is not a xml file, but a xml+html document:

?xml version=1.0 encoding=UTF-8?
newsList xlmns=http:// ... /newsList
html
head
meta http-equiv=Content-Type content=text/html; charset=Cp1252/


* If I use xmlout.output(doc, res.getOutputStream() );, I have an
exception (whole trace):

java.lang.IllegalStateException: getOutputStream() has already been
called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:599)
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:195)
at wicket.protocol.http.WebResponse.write(WebResponse.java:315)
at
wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:75)
at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:229)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)

To me it looks as if I wrote my xml file and wicket wants to write the
html code just behind it (just as it does when i use Response.write() ),
but it cannot because I already called getOutputStream().

I create the xml file on runtime and do not have a empty one in the same
directory as suggested in the rss examples, but I see not reason that is
the problem.

 what triggers that code?
The constructor:

public RequestXML() {
WebRequest req = (WebRequest) getRequest();
WebResponse res = (WebResponse) getResponse();

parametersToResponse(req.getParameterMap(), res);
} catch (IOException e) {
e.printStackTrace();
}
}

I want to use that page to request data out of a Firefox extension.
I appreciate every idea.

Regards
Daniel


 
 -igor
 
 
 On 1/22/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
 
 Hi!
 
 I want to load an XML-file from a wicket page concerning the html page
 parameters with javascript. The javascript part (load and parse xml)
 works fine and also the generated xml file is okay.
 
 I just always get an
 
 java.lang.IllegalStateException: getOutputStream() has already been
 called for this response
 at
 org.apache.catalina.connector.Response.getWriter(Response.java:599)
 at
 org.apache.catalina.connector.ResponseFacade.getWriter
 (ResponseFacade.java:195)
 at wicket.protocol.http.WebResponse.write(WebResponse.java:315)
 at
 
 wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:75)
 at wicket.protocol.http.WicketServlet.doGet
 (WicketServlet.java:229)
 [...]
 
 
 I did some research on this problem and found some workarounds for jsp.
 I also tried different combinations of Streams and Writers. Alsways that
 exception.
 
 The code:
 
 private void parametersToResponse(MapString, String params, Response
 res) throws IOException {
 res.setContentType(text/xml);
 
 logger.info(map:  + params);
 
 //  test for illegal keys
 if ( containsIllegalKeys(params) || params.isEmpty() ) {
 logger.warn(howtoString);
 res.write(howtoString); //works!
 } else {
 
 //

Re: [Wicket-user] Compound Property model and Palette

2007-01-23 Thread Nino Wael

If you want to, i'll send you our corrected palette.

These lines are especially interesting:

From palette:
protected void onModelChanged() {
super.onModelChanged();
if (recorderComponent != null) {
recorderComponent.reCreateModel();
}
}
From recorder:
public void reCreateModel() {

// construct the model string based on selection collection
IChoiceRenderer renderer = getPalette().getChoiceRenderer();
StringBuffer modelStringBuffer = new StringBuffer();

Iterator selection = ((Collection) 
getPalette().getModelObject())
.iterator();

while (selection.hasNext()) {

modelStringBuffer.append(renderer.getIdValue(selection.next(), 0));
if (selection.hasNext()) {
modelStringBuffer.append(seperator);
}
}

// Get values from modelstringbuffer

String modelString = modelStringBuffer.toString();

// Only add if not already added
String[] local = getValue().split(seperator);

for (int i = 0; local.length  i; i++) {
if (modelString.indexOf(local[i]) == -1) {
modelString += seperator + local[i];
}
}
updateIds(modelString);

}

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of samyem
Sent: 23. januar 2007 06:47
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Compound Property model and Palette


Thanks for the note. I've gone ahead with my own implementation of Palette
since my last comment to satisfy my particular needs which were beyond the
scope of what Wicket provided.


igor.vaynberg wrote:
 
 there have been many changes to the palette in the recent past, give it
 another try.
 
 -igor
 
 
 On 10/18/06, samyem [EMAIL PROTECTED] wrote:


 Hi Igor,
 No that didn't work. You have just added a new constructor signature, but
 not fixed the real problem. The problem is that when Palette is
 constructed,
 it tries to make a new RecorderComponent which reads the model at
 construction time. Since I am using the 1.x wicket, Palette does not know
 its parent container at construction time and hence it cannot find the
 compound property model set on the palette's container. To fix this,
 you'll
 have to make the Palette's components read from the model at render time
 and
 remove the logic from the constructors, like the other FormComponents are
 already doing. Please give it another try and I'll check again once you
 are
 done.

 Thanks,
 Samyem


 igor.vaynberg wrote:
 
  and its patched, let me know if it works.
 
  -Igor
 
 
  On 10/14/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  it is a limitation, i will patch it soon.
 
  -Igor
 
 
  On 10/14/06, samyem [EMAIL PROTECTED] wrote:
  
  
   Since the Palette does not allow you to implicitly use the
 container's
   compound model, there does not appear to be an obvious way for
 Palette
   to
   behave the same way as the other FormComponents. So I was wondering
 if
   this
   is a limitation of Palette or it was done this way by design?
  
  
   samyem wrote:
   
Is it possible for a Palette to take the CompoundPropertyModel set
 on
   the
form?
   
  
   --
   View this message in context:
 
 http://www.nabble.com/Compound-Property-model-and-Palette-tf2439928.html#a6812005
  
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
  
  
 
 -
   Using Tomcat but need to do more? Need to support web services,
   security?
   Get stuff done quickly with pre-integrated technology to make your
 job
   easier
   Download IBM WebSphere Application Server v.1.0.1 based on Apache
   Geronimo
  
 
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
 
 
 -
  Using Tomcat but need to do more? Need to support web services,
 security?
  Get stuff done quickly with pre-integrated technology to make your job
  easier
  Download IBM WebSphere Application Server v.1.0.1 based on Apache
 Geronimo
 
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

 --
 View this message in context:

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Otan


On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote:


...  in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean)...




You're very right. This is the major contributor to my confusion about
models when I was first studying Wicket. I don't want to vote because I'm no
one here and my vote is nothing. I just want to voice my opinion: I think
the solution would be for the wiki and book writers to give more weight and
clear explanations about models and relieve newbies from this confusion.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] spring integration question


yes and i rechecked it in.
Because the file you checked in is just plain wrong.
Those extra empty spaces don't make any sense!
Please recheck if it fails again for you and then test why those extra
spaces are in front of every empty line.

So i guess Windows Rules.. others just suck! :)

johan


On 1/23/07, Frank Bille [EMAIL PROTECTED] wrote:


On 1/23/07, Johan Compagner [EMAIL PROTECTED] wrote:

 it is strange isn't it
 now you fixed it so it works on the server


Hmm.. and it works on my machine as well. Windows Sucks(tm)

Frank

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] spring integration question


Johan Compagner wrote:
 So i guess Windows Rules.. others just suck! :)
To rule and to suck can go hand in hand as well :)



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Marc-Andre Houle


If it is user opinion wanted, for what I am it is -1.

I would be please with the change if I used wicket for a home hobby of
making something easy.  But the problem is that I'm working in a production
environment.  Every thing that will make 2.0  migration harder will make
sure that it will not get used soon in the industry.

The arguments are good, but I don't think it is worth it.

Marc

On 1/23/07, Otan [EMAIL PROTECTED] wrote:


On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote:

 ...  in fact, that term is actually ambiguous since the object
 implementing IModel might be informally understood to be the model
 object
 (which is not what we mean)...



You're very right. This is the major contributor to my confusion about
models when I was first studying Wicket. I don't want to vote because I'm no
one here and my vote is nothing. I just want to voice my opinion: I think
the solution would be for the wiki and book writers to give more weight and
clear explanations about models and relieve newbies from this confusion.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent

2007-01-23 Thread Marc-Andre Houle


never seen it before.

On 1/22/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


You better not look at it either as we're thinking about removing it! :)

Eelco


On 1/22/07, Ingram Chen [EMAIL PROTECTED] wrote:
 never use it! (what is that ? :-p

 On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  are you using Page.before/afterCallComponent? and if so what is the
 usecase?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent

2007-01-23 Thread Jean-Baptiste Quenot

* Igor Vaynberg:

 are you using Page.before/afterCallComponent?  and if so what is
 the usecase?

Not at all.
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Compound Property model and Palette

2007-01-23 Thread Jean-Baptiste Quenot

* Igor Vaynberg:

 there have been many changes to  the palette in the recent past,
 give it another try.

I would even say that the problem is fixed.
See https://issues.apache.org/jira/browse/WICKET-222
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent

2007-01-23 Thread Johannes Fahrenkrug

never heard of it, either :)

Igor Vaynberg wrote:
 are you using Page.before/afterCallComponent? and if so what is the 
 usecase?

 -igor

 

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent

2007-01-23 Thread Paolo Di Tommaso


No

On 1/23/07, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:


never heard of it, either :)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Any users getting an UnsupportedOperationException on 2.0 trunk?

2007-01-23 Thread TimOBrien


Igor, you got it.  My local SVN was a confusing hybrid of references to old
(sf.net) mixed with new (asf).  Apologies, and thanks.



igor.vaynberg wrote:
 
 strange, you seem to have a pretty old copy
 
 here what the latest looks like [1], notice line 1066 doesnt match what
 you
 have
 also have a look at how the messages are cleared [2] ... iterator is not
 used in clearRendered() which is what session.cleanupMessages() calls
 
 [1]
 http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/Session.java?view=annotate
 [2]
 http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/feedback/FeedbackMessages.java?view=annotate
 
 -igor
 
 
 
 On 1/22/07, TimOBrien [EMAIL PROTECTED] wrote:


 No doubt, I don't have the stack trace at hand, but I can point you to
 line
 1066 in cleanupFeedbackMessages() in Session.   The issue here is that
 the
 Iterator returned from the a CopyOnWriteArrayList throws this exception
 from
 a call to remove, set, or add.  Here's the quote from
 CopyOnWriteArrayList:

 Element-changing
 * operations on iterators themselves (remove, set, and add) are not
 * supported. These methods throw
 * ttUnsupportedOperationException/tt

 Problem was manifesting itself the first time a message was added to
 feedbackMessage


 igor.vaynberg wrote:
 
  your fix wont do, the list needs to be threadsafe
 
  can you please paste the stacktrace so we can see where the remove() is
  being called from?
 
  -igor
 
 
  On 1/22/07, TimOBrien [EMAIL PROTECTED] wrote:
 
 
  I updated my copy of trunk, and I kept on getting this message:
 
  java.lang.UnsupportedOperationException
 
  java.util.concurrent.CopyOnWriteArrayList$COWIterator.remove(
  CopyOnWriteArrayList.java:937)
  wicket.Session.cleanupFeedbackMessages(Session.java:1067)
 
  Tracked it down to CopyOnWriteArrayList in Session for
 feedbackMessages.
  Changing the type of feedbackMessage to ArrayList, and rebuilding
 seemed
  to
  fix the issue.  Any other users having a similar issue?
  --
  View this message in context:
 
 http://www.nabble.com/Any-users-getting-an-UnsupportedOperationException-on-2.0-trunk--tf3060997.html#a8511709
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to
 share
  your
  opinions on IT  business topics through brief surveys - and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
  your
  opinions on IT  business topics through brief surveys - and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

 --
 View this message in context:
 http://www.nabble.com/Any-users-getting-an-UnsupportedOperationException-on-2.0-trunk--tf3060997.html#a8513496
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/Any-users-getting-an-UnsupportedOperationException-on-2.0-trunk--tf3060997.html#a8523875
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent


Not using it (and I have also never seen it before).

 Erik.


igor.vaynberg wrote:
 
 are you using Page.before/afterCallComponent? and if so what is the
 usecase?
 
 -igor
 
 

-- 
View this message in context: 
http://www.nabble.com/-Wicket-user--SURVEY%3A-Are-you-using-Page.before-afterCallComponent-tf3060803.html#a8524051
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.

Eelco

On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:

i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):

public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}

we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.

i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).

i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.

Jonathan Locke wrote:

We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?

Jonathan Locke wrote:

Made a few more changes. I think it's getting shorter/better.

My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...

Jonathan Locke wrote:

Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:

In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.

It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?

Loren Rosen wrote:

I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.

In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.

igor.vaynberg wrote:

go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.

when you are done with the majority let us know and we will review the
changes.

-igor

On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:

When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.

Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving people a chance to comment
as I
go.
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8378321
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Scott Swank


-1 for changing the method signature
+1 for more model examples particularly contextual ones, i.e. with a form
you often use the form component itself as the model (I can work on this if
things go as I hope with our web ui proofs of concept -- otherwise I'll be
off learning JSF)

On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.

Eelco


On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:


 i'd like us to vote on changing IModel to this in 2.0 (i know it's very
 late, but please at least read my argument below and think about it for
a
 moment):

 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }

 we would also change getModelObject() to getValue() as well as any other
 related methods like getModelObjectAsString() to getValueAsString() (or
 valueAsString() if preferred).  there might be naming conflicts
somewhere or
 other problems, but i don't know of any offhand.

 i realize we're about to enter beta, but i feel like this matters since
our
 users have been telling us for some time now that models are hard to
 understand and it seems likely that the term 'model object' (as derived
from
 the IModel interface naming) is really not helping anyone to understand
 things.  in fact, that term is actually ambiguous since the object
 implementing IModel might be informally understood to be the model
object
 (which is not what we mean).

 i realize this change would affect the book and so eelco and martijn may
 very understandably not want to deal with that so i won't be upset if
this
 change can't happen.  but i'd like to see it if it's possible, so at any
 rate, i'm +1 and i think igor says he's +0.


 Jonathan Locke wrote:
 
 
  We did already break the model contract with 1.2/1.3... would
  get/setObject-get/setValue be a huge hassle?  Or am I spacing
something
  here?
 
 
  Jonathan Locke wrote:
 
 
  Made a few more changes.  I think it's getting shorter/better.
 
  My one regret looking at this documentation is that I wish
  IModel.get/setObject were actually IModel.get/setValue.  Or was there
  some crazy reason we didn't do this?  It would be much easier and
more
  natural to talk about a model's value this way...
 
 
  Jonathan Locke wrote:
 
 
  Nice work.  I made a few small changes and rephrased the first
paragraph
  to be even more specific.  Maybe it could be tweaked a little more,
but
  I think this sums it up better now:
 
  In Wicket, a model holds a value for a component to display and/or
  edit. How exactly this value is held is determined by a given
model's
  implementation of the wicket.model.IModel interface. This interface
  decouples a component from the data which forms its value. This in
turn
  decouples the whole Wicket framework from any and all details of
model
  storage, such as the details of a given persistence technology. As
far
  as Wicket itself is concerned, a model is anything that implements
the
  IModel interface, no matter how it might do that.
 
  It does feel like this is the best place to show the IModel
interface
  since readers will be wondering what it looks like already.  It
sounds
  scarier than it is, so why delay?
 
 
  Loren Rosen wrote:
 
  I've saved my rewritten version. (See
 
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
  Comments by everyone from experts to complete newbies
  are most welcome. Doubtless there are things that are confusing or
  flat-out wrong.
 
  In addition to rephrasing or rewriting a lot of material, and
adding a
  few things, I
  excised some details I thought would be distracting for a beginner.
  Some of this
  material is, I think, still useful, perhaps in a slightly more
advanced
  More about
  Models page.
 
 
  igor.vaynberg wrote:
 
  go ahead and edit the page...the wiki is versioned i think so we
can
  always
  roll back.
 
  when you are done with the majority let us know and we will review
the
  changes.
 
  -igor
 
 
  On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
 
 
  When I first started using Wicket I found the information on
models a
  little
  hard to follow. So now I'd like to revise the Working with
Wicket
  models
  wiki page
  (
 
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
  )
  to improve this. I'd be happy to outline what I think should be
  improved
  (though this is a little hard to do in detail short of simply
  annotating
  the
  page) or I can just plunge ahead and draft a revised page. If I
do
  the
  latter I could potentially post it somewhere else for comment
instead
  of
  directly replacing the existing page on the wiki. Perhaps we need
a
  'in
  draft' part of the wiki for working on long pages like this one.
 
  Actually, another alternative is for me to gradually introduce
  changes to
  the wiki page over a span of days, giving

Re: [Wicket-user] contributing to wicket-stuff or ?

Contributions to wicket-stuff are always welcome. You already have
write permissions correct? This sounds like something that would go
nicely in the wicket-contrib-examples project, where you could have
both the component and the example of how to use it. WDYT?

Eelco

On 1/22/07, Nino Wael [EMAIL PROTECTED] wrote:




 Hi



 I have some components that migth be interesting for others to have. The
 best one I'll describe below:



 Currently called dropdownpalette, and it's a combination of Igor's
 palette(although rewritten a bit, I belive that Igor have fixed the original
 palette so we should use that one) and a dropdown.



 The component works by having three models and a list plus a bit more.  When
 you chose something in the dropdown the palettes left side listbox are
 updated with values and the right side are cleared. Since the update are
 done with ajax, as base the left listbox are updated but you can specify
 additional slavecompnents that will be rerendered and updated after
 selection of a specific dropdown item.



 I've used reflection on this, you must provide a method, a provider and a
 parameter list, when creating the component. Snipplet:



 Creating the parameters:



 List params =
 new ArrayList();

 Object[] param
 = new Object[2];

 param[0] =
 IDataItem.class;

 param[1] =
 dataitemmodel;


 params.add(param);



 param = new
 Object[2];

 param[0] =
 Object.class;

 param[1] =
 object model;


 params.add(param);



 param = new
 Object[2];

 param[0] =
 Cube.class;

 param[1] =
 cubemodel;


 params.add(param);



 From the above you can see that  all parameters actually are Imodels but we
 also specify which kind of class the object retrieved from the model should
 be cast into.



 (pseudo creation of component)

 DropDownPalette
 ddp = new DropDownPalette(


id, dropdownmodel, dropdown
 items,


paletteleftmodel,
 paletterightmodel, dbprovider,


getAreas, params,
 slaveComponents)

 Form.add(ddp);



 So the string getAreas specify that dbprovide will be called when choosing
 a new thing in the dropdown, the method are called with the params list as
 parameters.



 So I guess this is a pretty generic component, although there are some setup
 with the parameter list the component should be easy to use, I think at
 least the reflection part should be useful if you have a bunch of components
 that almost does the same thing you should be able to create one component
 that fits all.



 Regards Nino


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] [OT] wicket expertise offered / Denmark

Good luck. And a user story or some other reference on the application
you built with Wicket would be a very welcome addition to the WIKI!

Eelco


On 1/22/07, Nino Wael [EMAIL PROTECTED] wrote:




 Hi,



 I was wondering if any off you guys would be interested in some wicket
 expertise, located somewhere near Copenhagen-Frederikssund in Denmark. Our
 current wicket project are almost running out, and the next project im off
 to do aren't wicket in fact im not even sure it's java basedL So just
 thought I'll give the user list's peeps a chance of getting a wicket guyJ



 Regards Nino


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] AttributeModifier disabled - Bug or Feature?


it happens :) no worries

-igor


On 1/23/07, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:


It was neither a bug nor a feature: I'm simply an idiot. I was using a
custom TextField which overrides isEnabled()... D'Oh!

Sorry for wasting your time with this, Igor!

- Johannes

Johannes Fahrenkrug wrote:
 I will. I'm already looking at the FormComponent code. I have to go now,
 but I'll get back to it tomorrow.

 - Johannes

 Igor Vaynberg wrote:

 i dont see where we read the disabled attribute in our code, can you
 try branch-1.x? or see where in wicket's code it thinks its disabled?

 -igor


 On 1/22/07, * Johannes Fahrenkrug* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Yes, that was also the first thing I thought of: I checked it with
 livehttpheaders and yes: they are being submitted by the browser.

 - Johannes

 Igor Vaynberg wrote:
  can you check if the value is actually being submitted by the
 browser?
 
  -igor
 
 
  On 1/22/07, *Johannes Fahrenkrug*  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
 
  Hi,
 
  I had a strange error I have a Panel with 3
 radiobuttons. They
  let
  me choose whether I want to pay by debit or credit or  if I
 want to be
  billed later.
  When I click on either of the radiobuttons, the
 corresponding input
  fields get enabled via JavaScript.
  On the Wicket side, I add
 
  new AttributeModifier(disabled, true, new
Model(disabled));
 
  to each input field that doesn't belong to the currently
 selected
  option
  (i.e. the credit and debit fields are disabled when my
payment
  method is
  bill me later).
 
  When I select one of the other radio buttons, the
 correspondig text
  fields get enabled, I enter the information, submit the
form
  but the
  model doesn't get updated!
 
  When I remove the adding of the AttributeModifier, everything
  works. So
  this means that Wicket notices that I'm adding a disabled
  AttributeModifier and keeps the field disabled even when I
 enable
  it on
  the webpage. Is this a feature or a bug?
 
  If I would have wanted to really truly disable the Wicket
 Textfield
  component, I would have called setEnabled on it. But I
 really just
  want to set the HTML property disabled...
 
  I'm looking forward to your input on this.
 
  - Johannes
 
 
 

-

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the
 chance to
  share your
  opinions on IT  business topics through brief surveys - and
 earn cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 


 
 

-

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance
 to share your
  opinions on IT  business topics through brief surveys - and
 earn cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 



 
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 



-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net 's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys - and earn
cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

Re: [Wicket-user] Exception on WebResponse Outputstream


or even better dont use a page at all, use a shared resource

-igor


On 1/23/07, Daniel Nüst [EMAIL PROTECTED] wrote:


Thank you very much, Johan!

I wrote my own XMLRequestTarget around your code and now it works.

Daniel

Johan Compagner schrieb:
 you can't just write to something in the constructor (thats in the
 event/request phase)

 make a RequestTarget that outputs that what you want and set that
 request target as the response request target
 on the request cycle

 RequestCycle.get().setRequestTarget(new IRequestTarget()
 {
void respond(RequestCycle requestCycle)
{
 Response rep = requestCycle.getResponse();
 rep.write(yourxml);
}
 });

 johan

 On 1/23/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Hi Igor!

 Igor Vaynberg schrieb:
  looks like you are trying to output your xml too late in the game
  (wicket has already written something to the request).
 I would rather guess it seems the other way around (and I will try
to
 explain the situation a bit better):

 * If I use res.write( xmlout.outputString( doc ) );, I do not get
the
 exeption, but the response is not a xml file, but a xml+html
document:

 ?xml version= 1.0 encoding=UTF-8?
 newsList xlmns=http:// ... /newsList
 html
 head
 meta http-equiv=Content-Type content=text/html;
charset=Cp1252/


 * If I use xmlout.output(doc, res.getOutputStream() );, I have an
 exception (whole trace):

 java.lang.IllegalStateException: getOutputStream() has already been
 called for this response
 at
 org.apache.catalina.connector.Response.getWriter(Response.java:599)
 at
 org.apache.catalina.connector.ResponseFacade.getWriter(
ResponseFacade.java:195)
 at wicket.protocol.http.WebResponse.write(WebResponse.java:315)
 at
 wicket.protocol.http.BufferedWebResponse.close(
BufferedWebResponse.java:75)
 at
 wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:229)
 at javax.servlet.http.HttpServlet.service (HttpServlet.java
:689)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java
:802)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
 at
 org.apache.catalina.core.StandardContextValve.invoke
 (StandardContextValve.java:178)
 at
 org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:126)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:105)

 at
 org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:148)
 at
 org.apache.coyote.http11.Http11Processor.process
 (Http11Processor.java:869)
 at

org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:664)
 at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
 (PoolTcpEndpoint.java:527)
 at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
 at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java
 :684)
 at java.lang.Thread.run(Unknown Source)

 To me it looks as if I wrote my xml file and wicket wants to write
the
 html code just behind it (just as it does when i use Response.write()
),
 but it cannot because I already called getOutputStream().

 I create the xml file on runtime and do not have a empty one in the
same
 directory as suggested in the rss examples, but I see not reason
that is
 the problem.

  what triggers that code?
 The constructor:

 public RequestXML() {
 WebRequest req = (WebRequest) getRequest();
 WebResponse res = (WebResponse) getResponse();

 parametersToResponse(req.getParameterMap(), res);
 } catch (IOException e) {
 e.printStackTrace();
 }
 }

 I want to use that page to request data out of a Firefox extension.
 I appreciate every idea.

 Regards
 Daniel


 
  -igor
 
 
  On 1/22/07, *Daniel Nüst* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]  wrote:
 
  Hi!
 
  I want to load an XML-file from a wicket page concerning the
 html page
  parameters with javascript. The javascript part (load and
 parse xml)
  works fine and also the generated xml

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Matthijs Wensveen

+1 Don't know if my vote counts or not, but anyway.

I'm one of those users that had trouble with the ambiguity between model 
object (as in the IModel instance) and modelObject (the object contained 
by the model). Worse, In my project's team all the modelObjects were 
classes with the naming convention XXXModel so we had IModels containing 
modelObjects that were XXXModels. If that isn't an example of bad 
naming, then what is? :D

In my opinion models containing values that are (of course) objects is 
much clearer and would prevent this kind of madness. Luckily Eclipse has 
great refactoring features, so XXXModel soon became XXXModelObject.

Matthijs

Eelco Hillenius wrote:
 -1. Regardless of whether the change is for the better, it will break
 way too much existing code not to mention the tutorials on the
 internet etc.

 Eelco


 On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
   
 i'd like us to vote on changing IModel to this in 2.0 (i know it's very
 late, but please at least read my argument below and think about it for a
 moment):

 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }

 we would also change getModelObject() to getValue() as well as any other
 related methods like getModelObjectAsString() to getValueAsString() (or
 valueAsString() if preferred).  there might be naming conflicts somewhere or
 other problems, but i don't know of any offhand.

 i realize we're about to enter beta, but i feel like this matters since our
 users have been telling us for some time now that models are hard to
 understand and it seems likely that the term 'model object' (as derived from
 the IModel interface naming) is really not helping anyone to understand
 things.  in fact, that term is actually ambiguous since the object
 implementing IModel might be informally understood to be the model object
 (which is not what we mean).

 i realize this change would affect the book and so eelco and martijn may
 very understandably not want to deal with that so i won't be upset if this
 change can't happen.  but i'd like to see it if it's possible, so at any
 rate, i'm +1 and i think igor says he's +0.


 Jonathan Locke wrote:
 
 We did already break the model contract with 1.2/1.3... would
 get/setObject-get/setValue be a huge hassle?  Or am I spacing something
 here?


 Jonathan Locke wrote:
   
 Made a few more changes.  I think it's getting shorter/better.

 My one regret looking at this documentation is that I wish
 IModel.get/setObject were actually IModel.get/setValue.  Or was there
 some crazy reason we didn't do this?  It would be much easier and more
 natural to talk about a model's value this way...


 Jonathan Locke wrote:
 
 Nice work.  I made a few small changes and rephrased the first paragraph
 to be even more specific.  Maybe it could be tweaked a little more, but
 I think this sums it up better now:

 In Wicket, a model holds a value for a component to display and/or
 edit. How exactly this value is held is determined by a given model's
 implementation of the wicket.model.IModel interface. This interface
 decouples a component from the data which forms its value. This in turn
 decouples the whole Wicket framework from any and all details of model
 storage, such as the details of a given persistence technology. As far
 as Wicket itself is concerned, a model is anything that implements the
 IModel interface, no matter how it might do that.

 It does feel like this is the best place to show the IModel interface
 since readers will be wondering what it looks like already.  It sounds
 scarier than it is, so why delay?


 Loren Rosen wrote:
   
 I've saved my rewritten version. (See
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
 Comments by everyone from experts to complete newbies
 are most welcome. Doubtless there are things that are confusing or
 flat-out wrong.

 In addition to rephrasing or rewriting a lot of material, and adding a
 few things, I
 excised some details I thought would be distracting for a beginner.
 Some of this
 material is, I think, still useful, perhaps in a slightly more advanced
 More about
 Models page.


 igor.vaynberg wrote:
 
 go ahead and edit the page...the wiki is versioned i think so we can
 always
 roll back.

 when you are done with the majority let us know and we will review the
 changes.

 -igor


 On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
   
 When I first started using Wicket I found the information on models a
 little
 hard to follow. So now I'd like to revise the Working with Wicket
 models
 wiki page
 (
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
 )
 to improve this. I'd be happy to outline what I think should be
 improved
 (though this is a little hard to do in detail short of simply
 annotating
 the
 page) or I can just plunge ahead and draft a revised page. If I do
 the
 latter I could

Re: [Wicket-user] SURVEY: Are you using Page.before/afterCallComponent

2007-01-23 Thread Francis Amanfo


It's been lying in coma for too long a time so it's time you pull the plug
on him. :-)

Frn6

On 1/22/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


are you using Page.before/afterCallComponent? and if so what is the
usecase?

-igor


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user






--
Beware of bugs in the above code;
I have only proved it correct, not tried it.
   -Donald Knuth
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Gustavo Hexsel

+0 for changing, except not sure it's what Johnathan suggested.

My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...).  They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective.   The methods wouldn't even have to change
that much then.

 []s Gus



On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 +1 Don't know if my vote counts or not, but anyway.

 I'm one of those users that had trouble with the ambiguity between model
 object (as in the IModel instance) and modelObject (the object contained
 by the model). Worse, In my project's team all the modelObjects were
 classes with the naming convention XXXModel so we had IModels containing
 modelObjects that were XXXModels. If that isn't an example of bad
 naming, then what is? :D

 In my opinion models containing values that are (of course) objects is
 much clearer and would prevent this kind of madness. Luckily Eclipse has
 great refactoring features, so XXXModel soon became XXXModelObject.

 Matthijs

 Eelco Hillenius wrote:
  -1. Regardless of whether the change is for the better, it will break
  way too much existing code not to mention the tutorials on the
  internet etc.
 
  Eelco
 
 
  On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
 
  i'd like us to vote on changing IModel to this in 2.0 (i know it's very
  late, but please at least read my argument below and think about it for a
  moment):
 
  public interface IModelV extends IDetachable
  {
V getValue();
void setValue(V value);
  }
 
  we would also change getModelObject() to getValue() as well as any other
  related methods like getModelObjectAsString() to getValueAsString() (or
  valueAsString() if preferred).  there might be naming conflicts somewhere 
  or
  other problems, but i don't know of any offhand.
 
  i realize we're about to enter beta, but i feel like this matters since our
  users have been telling us for some time now that models are hard to
  understand and it seems likely that the term 'model object' (as derived 
  from
  the IModel interface naming) is really not helping anyone to understand
  things.  in fact, that term is actually ambiguous since the object
  implementing IModel might be informally understood to be the model object
  (which is not what we mean).
 
  i realize this change would affect the book and so eelco and martijn may
  very understandably not want to deal with that so i won't be upset if this
  change can't happen.  but i'd like to see it if it's possible, so at any
  rate, i'm +1 and i think igor says he's +0.
 
 
  Jonathan Locke wrote:
 
  We did already break the model contract with 1.2/1.3... would
  get/setObject-get/setValue be a huge hassle?  Or am I spacing something
  here?
 
 
  Jonathan Locke wrote:
 
  Made a few more changes.  I think it's getting shorter/better.
 
  My one regret looking at this documentation is that I wish
  IModel.get/setObject were actually IModel.get/setValue.  Or was there
  some crazy reason we didn't do this?  It would be much easier and more
  natural to talk about a model's value this way...
 
 
  Jonathan Locke wrote:
 
  Nice work.  I made a few small changes and rephrased the first paragraph
  to be even more specific.  Maybe it could be tweaked a little more, but
  I think this sums it up better now:
 
  In Wicket, a model holds a value for a component to display and/or
  edit. How exactly this value is held is determined by a given model's
  implementation of the wicket.model.IModel interface. This interface
  decouples a component from the data which forms its value. This in turn
  decouples the whole Wicket framework from any and all details of model
  storage, such as the details of a given persistence technology. As far
  as Wicket itself is concerned, a model is anything that implements the
  IModel interface, no matter how it might do that.
 
  It does feel like this is the best place to show the IModel interface
  since readers will be wondering what it looks like already.  It sounds
  scarier than it is, so why delay?
 
 
  Loren Rosen wrote:
 
  I've saved my rewritten version. (See
  http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
  Comments by everyone from experts to complete newbies
  are most welcome. Doubtless there are things that are confusing or
  flat-out wrong.
 
  In addition to rephrasing or rewriting a lot of material, and adding a
  few things, I
  excised some details I thought would be distracting for a beginner.
  Some of this
  material is, I think, still useful, perhaps in a slightly more advanced
  More about
  Models page.
 
 
  igor.vaynberg wrote:
 
  go ahead and edit the page...the wiki is versioned i think so we can
  always

Re: [Wicket-user] VOTE: IModel and 'model object' name change

I voted -1, but here is my opinion about the change proper.

 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }

This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.


 we would also change getModelObject() to getValue() as well as any other
 related methods like getModelObjectAsString() to getValueAsString() (or
 valueAsString() if preferred).  there might be naming conflicts somewhere or
 other problems, but i don't know of any offhand.

Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.

Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).

The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change



yeah.  i agree.  if we did anything it would be better to change IModel as i
said,
but then just deprecate getModelObject() and add a preferred version as 
getModelValue() as johan suggested.  this would only break code that
directly
uses IModel (a more limited number of users).


Eelco Hillenius wrote:
 
 I voted -1, but here is my opinion about the change proper.
 
 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }
 
 This would be for the better imo, though I don't hate the original
 getObject *that* much. It's just what you are used to and I think
 documentation on how models should be used is a lot more important.
 
 
 we would also change getModelObject() to getValue() as well as any other
 related methods like getModelObjectAsString() to getValueAsString() (or
 valueAsString() if preferred).  there might be naming conflicts somewhere
 or
 other problems, but i don't know of any offhand.
 
 Tbh, I actually don't think Component#getValue is for the better. I
 think Component#getModelObject is way clearer than Component#getValue.
 In the end I think both value and object are ambiguous, and this
 should be fixed by documentation and examples.
 
 Btw, If there is *anything* I never liked about the whole model
 business, it is the fact that Component has methods to get the model
 value in the first place (getModelObject etc).
 
 The indirection that IModel provides is something to get used to. It
 is one of the places where we traded clarity and simplicity for
 flexibility. I think it'll be hard to grasp for newbies no matter the
 naming, so the better our documentation and examples are, the quicker
 they will be able to wrap their head around it.
 
 Eelco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change


it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or the
object inside the model object?

-igor


On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


I voted -1, but here is my opinion about the change proper.

 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }

This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.


 we would also change getModelObject() to getValue() as well as any other
 related methods like getModelObjectAsString() to getValueAsString() (or
 valueAsString() if preferred).  there might be naming conflicts
somewhere or
 other problems, but i don't know of any offhand.

Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.

Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).

The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.

Eelco


On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
 +0 for changing, except not sure it's what Johnathan suggested.

 My problem is with using the word Model at all for the objects that
 access model properties (maybe they should be ModelAccessors,
 ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
 along the lines... then ReflectionModelAccessor or
 CompositeModelAccessor, ...).  They're not really models in any sense
 that existing software patterns might agree, except maybe from the
 framework-only perspective.   The methods wouldn't even have to change
 that much then.

  []s Gus



 On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
  +1 Don't know if my vote counts or not, but anyway.
 
  I'm one of those users that had trouble with the ambiguity between model
  object (as in the IModel instance) and modelObject (the object contained
  by the model). Worse, In my project's team all the modelObjects were
  classes with the naming convention XXXModel so we had IModels containing
  modelObjects that were XXXModels. If that isn't an example of bad
  naming, then what is? :D
 
  In my opinion models containing values that are (of course) objects is
  much clearer and would prevent this kind of madness. Luckily Eclipse has
  great refactoring features, so XXXModel soon became XXXModelObject.
 
  Matthijs
 
  Eelco Hillenius wrote:
   -1. Regardless of whether the change is for the better, it will break
   way too much existing code not to mention the tutorials on the
   internet etc.
  
   Eelco
  
  
   On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
  
   i'd like us to vote on changing IModel to this in 2.0 (i know it's very
   late, but please at least read my argument below and think about it for a
   moment):
  
   public interface IModelV extends IDetachable
   {
 V getValue();
 void setValue(V value);
   }
  
   we would also change getModelObject() to getValue() as well as any other
   related methods like getModelObjectAsString() to getValueAsString() (or
   valueAsString() if preferred).  there might be naming conflicts 
   somewhere or
   other problems, but i don't know of any offhand.
  
   i realize we're about to enter beta, but i feel like this matters since 
   our
   users have been telling us for some time now that models are hard to
   understand and it seems likely that the term 'model object' (as derived 
   from
   the IModel interface naming) is really not helping anyone to understand
   things.  in fact, that term is actually ambiguous since the object
   implementing IModel might be informally understood to be the model object
   (which is not what we mean).
  
   i realize this change would affect the book and so eelco and martijn may
   very understandably not want to deal with that so i won't be upset if 
   this
   change can't happen.  but i'd like to see it if it's possible, so at any
   rate, i'm +1 and i think igor says he's +0.
  
  
   Jonathan Locke wrote:
  
   We did already break the model contract with 1.2/1.3... would
   get/setObject-get/setValue be a huge hassle?  Or am I spacing something
   here?
  
  
   Jonathan Locke wrote:
  
   Made a few more changes.  I think it's getting shorter/better.
  
   My one regret looking at this documentation is that I wish
   IModel.get/setObject were actually IModel.get/setValue.  Or was there
   some crazy reason we didn't do this?  It would be much easier and more
   natural to talk about a model's value this way...
  
  
   Jonathan Locke wrote:
  
   Nice work.  I made a few small changes and rephrased the first 
   paragraph
   to be even more specific.  Maybe it could be tweaked a little more, 
   but
   I think this sums it up better now:
  
   In Wicket, a model holds a value for a component to display and/or
   edit. How exactly this value is held is determined by a given model's
   implementation of the wicket.model.IModel interface. This interface
   decouples a component from the data which forms its value. This in 
   turn
   decouples the whole Wicket framework from any and all details of model
   storage, such as the details of a given persistence technology. As far
   as Wicket itself is concerned, a model is anything that implements the
   IModel interface, no matter how it might do that.
  
   It does feel like this is the best place to show the IModel interface
   since readers will be wondering what it looks like already.  It sounds
   scarier than it is, so why delay?
  
  
   Loren Rosen wrote:
  
   I've saved my rewritten version. (See
   http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
   Comments by everyone from experts to complete newbies
   are most welcome. Doubtless there are things that are confusing or

Re: [Wicket-user] VOTE: IModel and 'model object' name change



You make a good point.  Something like IModelLocator would be a 
clearer name for IModel.  then its methods could be called get/setModel.
As you point out, IModel is only the model from the framework's 
perspective.  From the user's it is a model locator and the actual
model is the object returned by the locator interface.  Maybe we
can consider this for 3.0 if there's strong agreement by then.


Gustavo Hexsel-3 wrote:
 
 +0 for changing, except not sure it's what Johnathan suggested.
 
 My problem is with using the word Model at all for the objects that
 access model properties (maybe they should be ModelAccessors,
 ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
 along the lines... then ReflectionModelAccessor or
 CompositeModelAccessor, ...).  They're not really models in any sense
 that existing software patterns might agree, except maybe from the
 framework-only perspective.   The methods wouldn't even have to change
 that much then.
 
  []s Gus
 
 
 
 On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 +1 Don't know if my vote counts or not, but anyway.

 I'm one of those users that had trouble with the ambiguity between model
 object (as in the IModel instance) and modelObject (the object contained
 by the model). Worse, In my project's team all the modelObjects were
 classes with the naming convention XXXModel so we had IModels containing
 modelObjects that were XXXModels. If that isn't an example of bad
 naming, then what is? :D

 In my opinion models containing values that are (of course) objects is
 much clearer and would prevent this kind of madness. Luckily Eclipse has
 great refactoring features, so XXXModel soon became XXXModelObject.

 Matthijs

 Eelco Hillenius wrote:
  -1. Regardless of whether the change is for the better, it will break
  way too much existing code not to mention the tutorials on the
  internet etc.
 
  Eelco
 
 
  On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
 
  i'd like us to vote on changing IModel to this in 2.0 (i know it's
 very
  late, but please at least read my argument below and think about it
 for a
  moment):
 
  public interface IModelV extends IDetachable
  {
V getValue();
void setValue(V value);
  }
 
  we would also change getModelObject() to getValue() as well as any
 other
  related methods like getModelObjectAsString() to getValueAsString()
 (or
  valueAsString() if preferred).  there might be naming conflicts
 somewhere or
  other problems, but i don't know of any offhand.
 
  i realize we're about to enter beta, but i feel like this matters
 since our
  users have been telling us for some time now that models are hard to
  understand and it seems likely that the term 'model object' (as
 derived from
  the IModel interface naming) is really not helping anyone to
 understand
  things.  in fact, that term is actually ambiguous since the object
  implementing IModel might be informally understood to be the model
 object
  (which is not what we mean).
 
  i realize this change would affect the book and so eelco and martijn
 may
  very understandably not want to deal with that so i won't be upset if
 this
  change can't happen.  but i'd like to see it if it's possible, so at
 any
  rate, i'm +1 and i think igor says he's +0.
 
 
  Jonathan Locke wrote:
 
  We did already break the model contract with 1.2/1.3... would
  get/setObject-get/setValue be a huge hassle?  Or am I spacing
 something
  here?
 
 
  Jonathan Locke wrote:
 
  Made a few more changes.  I think it's getting shorter/better.
 
  My one regret looking at this documentation is that I wish
  IModel.get/setObject were actually IModel.get/setValue.  Or was
 there
  some crazy reason we didn't do this?  It would be much easier and
 more
  natural to talk about a model's value this way...
 
 
  Jonathan Locke wrote:
 
  Nice work.  I made a few small changes and rephrased the first
 paragraph
  to be even more specific.  Maybe it could be tweaked a little more,
 but
  I think this sums it up better now:
 
  In Wicket, a model holds a value for a component to display and/or
  edit. How exactly this value is held is determined by a given
 model's
  implementation of the wicket.model.IModel interface. This interface
  decouples a component from the data which forms its value. This in
 turn
  decouples the whole Wicket framework from any and all details of
 model
  storage, such as the details of a given persistence technology. As
 far
  as Wicket itself is concerned, a model is anything that implements
 the
  IModel interface, no matter how it might do that.
 
  It does feel like this is the best place to show the IModel
 interface
  since readers will be wondering what it looks like already.  It
 sounds
  scarier than it is, so why delay?
 
 
  Loren Rosen wrote:
 
  I've saved my rewritten version. (See
 
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
  Comments by everyone from experts to complete newbies
  are most

Re: [Wicket-user] VOTE: IModel and 'model object' name change



yes.  that is the major concern.

for now, eelco could put a callout box in the book with a warning about
this ambiguity.  we could also do the same in the javadoc for getModel()
and getModelObject() so any rare people who actually read the docs 
won't be lost.


igor.vaynberg wrote:
 
 it would be Component.getModelValue() not Component.getModelObject() i
 think. what this disambiguates is what object you are referring to. the
 problem is that IModel impl itself is an object, so when you say
 component.getModelObject() what do you really want? the model object or
 the
 object inside the model object?
 
 -igor
 
 
 On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:

 I voted -1, but here is my opinion about the change proper.

  public interface IModelV extends IDetachable
  {
V getValue();
void setValue(V value);
  }

 This would be for the better imo, though I don't hate the original
 getObject *that* much. It's just what you are used to and I think
 documentation on how models should be used is a lot more important.


  we would also change getModelObject() to getValue() as well as any
 other
  related methods like getModelObjectAsString() to getValueAsString() (or
  valueAsString() if preferred).  there might be naming conflicts
 somewhere or
  other problems, but i don't know of any offhand.

 Tbh, I actually don't think Component#getValue is for the better. I
 think Component#getModelObject is way clearer than Component#getValue.
 In the end I think both value and object are ambiguous, and this
 should be fixed by documentation and examples.

 Btw, If there is *anything* I never liked about the whole model
 business, it is the fact that Component has methods to get the model
 value in the first place (getModelObject etc).

 The indirection that IModel provides is something to get used to. It
 is one of the places where we traded clarity and simplicity for
 flexibility. I think it'll be hard to grasp for newbies no matter the
 naming, so the better our documentation and examples are, the quicker
 they will be able to wrap their head around it.

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526645
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.

Eelco

On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 it would be Component.getModelValue() not Component.getModelObject() i
 think. what this disambiguates is what object you are referring to. the
 problem is that IModel impl itself is an object, so when you say
 component.getModelObject () what do you really want? the model object or the
 object inside the model object?

 -igor


 On 1/23/07, Eelco Hillenius  [EMAIL PROTECTED] wrote:
 
  I voted -1, but here is my opinion about the change proper.
 
   public interface IModelV extends IDetachable
   {
 V getValue();
 void setValue(V value);
   }
 
  This would be for the better imo, though I don't hate the original
  getObject *that* much. It's just what you are used to and I think
  documentation on how models should be used is a lot more important.
 
 
   we would also change getModelObject() to getValue() as well as any other
   related methods like getModelObjectAsString() to getValueAsString() (or
   valueAsString() if preferred).  there might be naming conflicts
 somewhere or
   other problems, but i don't know of any offhand.
 
  Tbh, I actually don't think Component#getValue is for the better. I
  think Component#getModelObject is way clearer than Component#getValue.
  In the end I think both value and object are ambiguous, and this
  should be fixed by documentation and examples.
 
  Btw, If there is *anything* I never liked about the whole model
  business, it is the fact that Component has methods to get the model
  value in the first place (getModelObject etc).
 
  The indirection that IModel provides is something to get used to. It
  is one of the places where we traded clarity and simplicity for
  flexibility. I think it'll be hard to grasp for newbies no matter the
  naming, so the better our documentation and examples are, the quicker
  they will be able to wrap their head around it.
 
  Eelco
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
  opinions on IT  business topics through brief surveys - and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change



geez, this makes so much sense like this!  ;-)


Eelco Hillenius wrote:
 
 Agreed. We have been discussing that in the past as well.
 IModelLocator for instance might have been a better name. And
 IModelLocator could then have get/setModel, as that's the real model
 value you're looking at.
 
 Eelco
 
 
 On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
 +0 for changing, except not sure it's what Johnathan suggested.

 My problem is with using the word Model at all for the objects that
 access model properties (maybe they should be ModelAccessors,
 ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
 along the lines... then ReflectionModelAccessor or
 CompositeModelAccessor, ...).  They're not really models in any sense
 that existing software patterns might agree, except maybe from the
 framework-only perspective.   The methods wouldn't even have to change
 that much then.

  []s Gus



 On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
  +1 Don't know if my vote counts or not, but anyway.
 
  I'm one of those users that had trouble with the ambiguity between
 model
  object (as in the IModel instance) and modelObject (the object
 contained
  by the model). Worse, In my project's team all the modelObjects were
  classes with the naming convention XXXModel so we had IModels
 containing
  modelObjects that were XXXModels. If that isn't an example of bad
  naming, then what is? :D
 
  In my opinion models containing values that are (of course) objects is
  much clearer and would prevent this kind of madness. Luckily Eclipse
 has
  great refactoring features, so XXXModel soon became XXXModelObject.
 
  Matthijs
 
  Eelco Hillenius wrote:
   -1. Regardless of whether the change is for the better, it will break
   way too much existing code not to mention the tutorials on the
   internet etc.
  
   Eelco
  
  
   On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
  
   i'd like us to vote on changing IModel to this in 2.0 (i know it's
 very
   late, but please at least read my argument below and think about it
 for a
   moment):
  
   public interface IModelV extends IDetachable
   {
 V getValue();
 void setValue(V value);
   }
  
   we would also change getModelObject() to getValue() as well as any
 other
   related methods like getModelObjectAsString() to getValueAsString()
 (or
   valueAsString() if preferred).  there might be naming conflicts
 somewhere or
   other problems, but i don't know of any offhand.
  
   i realize we're about to enter beta, but i feel like this matters
 since our
   users have been telling us for some time now that models are hard to
   understand and it seems likely that the term 'model object' (as
 derived from
   the IModel interface naming) is really not helping anyone to
 understand
   things.  in fact, that term is actually ambiguous since the object
   implementing IModel might be informally understood to be the model
 object
   (which is not what we mean).
  
   i realize this change would affect the book and so eelco and martijn
 may
   very understandably not want to deal with that so i won't be upset
 if this
   change can't happen.  but i'd like to see it if it's possible, so at
 any
   rate, i'm +1 and i think igor says he's +0.
  
  
   Jonathan Locke wrote:
  
   We did already break the model contract with 1.2/1.3... would
   get/setObject-get/setValue be a huge hassle?  Or am I spacing
 something
   here?
  
  
   Jonathan Locke wrote:
  
   Made a few more changes.  I think it's getting shorter/better.
  
   My one regret looking at this documentation is that I wish
   IModel.get/setObject were actually IModel.get/setValue.  Or was
 there
   some crazy reason we didn't do this?  It would be much easier and
 more
   natural to talk about a model's value this way...
  
  
   Jonathan Locke wrote:
  
   Nice work.  I made a few small changes and rephrased the first
 paragraph
   to be even more specific.  Maybe it could be tweaked a little
 more, but
   I think this sums it up better now:
  
   In Wicket, a model holds a value for a component to display
 and/or
   edit. How exactly this value is held is determined by a given
 model's
   implementation of the wicket.model.IModel interface. This
 interface
   decouples a component from the data which forms its value. This
 in turn
   decouples the whole Wicket framework from any and all details of
 model
   storage, such as the details of a given persistence technology.
 As far
   as Wicket itself is concerned, a model is anything that
 implements the
   IModel interface, no matter how it might do that.
  
   It does feel like this is the best place to show the IModel
 interface
   since readers will be wondering what it looks like already.  It
 sounds
   scarier than it is, so why delay?
  
  
   Loren Rosen wrote:
  
   I've saved my rewritten version. (See
  
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
   Comments by everyone from experts to

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Frank Silbermann


I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.

At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern).  If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().

(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components.  Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change



yeah.  i agree.  if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested.  this would only break code that
directly uses IModel (a more limited number of users).


Eelco Hillenius wrote:
 
 I voted -1, but here is my opinion about the change proper.
 
 public interface IModelV extends IDetachable
 {
   V getValue();
   void setValue(V value);
 }
 
 This would be for the better imo, though I don't hate the original
 getObject *that* much. It's just what you are used to and I think
 documentation on how models should be used is a lot more important.
 
 
 we would also change getModelObject() to getValue() as well as any
other
 related methods like getModelObjectAsString() to getValueAsString()
(or
 valueAsString() if preferred).  there might be naming conflicts
somewhere
 or
 other problems, but i don't know of any offhand.
 
 Tbh, I actually don't think Component#getValue is for the better. I
 think Component#getModelObject is way clearer than Component#getValue.
 In the end I think both value and object are ambiguous, and this
 should be fixed by documentation and examples.
 
 Btw, If there is *anything* I never liked about the whole model
 business, it is the fact that Component has methods to get the model
 value in the first place (getModelObject etc).
 
 The indirection that IModel provides is something to get used to. It
 is one of the places where we traded clarity and simplicity for
 flexibility. I think it'll be hard to grasp for newbies no matter the
 naming, so the better our documentation and examples are, the quicker
 they will be able to wrap their head around it.
 
 Eelco
 


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
 opinions on IT  business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

Yeah, the only real argument for that method other than brevity is that you
could override it.
It would be unreliable outside the core though and I can't think of a reason
to do that offhand.

Eelco Hillenius wrote:

getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.

Eelco

On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject () what do you really want? the model object or
the
object inside the model object?

-igor

On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:

I voted -1, but here is my opinion about the change proper.

public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}

This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.

we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.

Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.

Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).

The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526768
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

what do you think of gustav and eelco's IModelLocator / get/setModel idea?

Frank Silbermann wrote:

I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.

At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern). If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().

(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components. Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change

yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).

Eelco Hillenius wrote:

I voted -1, but here is my opinion about the change proper.

public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}

we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.

Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526796
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread Frank Silbermann

Yes, perhaps a better way to avoid overloading the word Model or
ModelObject is to use those words to refer to that which is wrapped
(usually a non-wicket oriented business object), and use something else
for the class which does the wrapping and provides access to the wicket
page component.

However, I'm not that keen on the name IModelLocator, as the current
IModel does many things other than merely locating the model.  It
provides string-based access methods to the model's parts; it handles
persistance or detachability, etc.

So I'd prefer to make get/setModel methods of an interface named
IModelManager or IModelWrapper.

The verbs Manage and Wrap are still somewhat vague, but there's only
so much that can be done to tersely document a class that does well lots
more than just one thing.

At least IModelManager or IModelWrapper are not ambiguous (as is
ModelObject), and avoids overloading the word Model.
  


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:55 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change



what do you think of gustav and eelco's IModelLocator / get/setModel
idea?


Frank Silbermann wrote:
 
 
 I don't care much for getValue() because to me the word value 
 suggests atomic value (or even atomic constant) -- which is not 
 the general case.
 
 At first I thought of recommending getBusinessObject() to distinguish 
 the result from the framework-oriented model classes, but that could 
 be confusing if it were common practices to embed wicket models inside

 of wicket models (the Decorator pattern).  If that's they case, I 
 would deprecate getModelObject() and replace it with
getUnwrappedModel().
 
 (Obviously, wicket documentation must somewhere explain the necessity 
 of _wrapping_ business objects in Wicket model classes to be accessed 
 by wicket components.  Once that process is understood, multiple 
 levels of wrapping should not be too difficult to understand.)
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Jonathan Locke
 Sent: Tuesday, January 23, 2007 11:35 AM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
 
 
 
 yeah.  i agree.  if we did anything it would be better to change 
 IModel as i said, but then just deprecate getModelObject() and add a 
 preferred version as
 getModelValue() as johan suggested.  this would only break code that 
 directly uses IModel (a more limited number of users).
 
 
 Eelco Hillenius wrote:
 
 I voted -1, but here is my opinion about the change proper.
 
 public interface IModelV extends IDetachable {
   V getValue();
   void setValue(V value);
 }
 
 This would be for the better imo, though I don't hate the original 
 getObject *that* much. It's just what you are used to and I think 
 documentation on how models should be used is a lot more important.
 
 
 we would also change getModelObject() to getValue() as well as any
 other
 related methods like getModelObjectAsString() to getValueAsString()
 (or
 valueAsString() if preferred).  there might be naming conflicts
 somewhere
 or
 other problems, but i don't know of any offhand.
 
 Tbh, I actually don't think Component#getValue is for the better. I 
 think Component#getModelObject is way clearer than
Component#getValue.
 In the end I think both value and object are ambiguous, and this 
 should be fixed by documentation and examples.
 
 Btw, If there is *anything* I never liked about the whole model 
 business, it is the fact that Component has methods to get the model 
 value in the first place (getModelObject etc).
 
 The indirection that IModel provides is something to get used to. It 
 is one of the places where we traded clarity and simplicity for 
 flexibility. I think it'll be hard to grasp for newbies no matter the

 naming, so the better our documentation and examples are, the quicker

 they will be able to wrap their head around it.
 
 Eelco
 

 --
 --
 -
 Take Surveys. Earn Cash. Influence the Future of IT Join 
 SourceForge.net's Techsay panel and you'll get the chance to
 share
 your
 opinions on IT  business topics through brief surveys - and earn 
 cash

 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEV
 DE
 V
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 --
 View this message in context:
 http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-pa
 ge
 -tf3016921.html#a8526349
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 --
 --
 -
 Take Surveys. Earn Cash. Influence the Future of IT Join

Re: [Wicket-user] spring integration question

2007-01-23 Thread Frank Bille


Now it works here as well. :)

Good job

On 1/23/07, Johan Compagner [EMAIL PROTECTED] wrote:


yes and i rechecked it in.
Because the file you checked in is just plain wrong.
Those extra empty spaces don't make any sense!
Please recheck if it fails again for you and then test why those extra
spaces are in front of every empty line.

So i guess Windows Rules.. others just suck! :)

johan


On 1/23/07, Frank Bille [EMAIL PROTECTED]  wrote:

 On 1/23/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  it is strange isn't it
  now you fixed it so it works on the server


 Hmm.. and it works on my machine as well. Windows Sucks(tm)

 Frank


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash

 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] [wicket 1.2.4] JIRA issue? Ampersand char problem in wicket.markup.html.link.ExternalLink.java

2007-01-23 Thread Kadir Sener GUMUS


Hi all,
i experienced a problem with href attribute of rendered ExternalLink.
In our application, i needed to parse rendered html in a SaxParser
implementation. But i couldnt!  When i looked in source codes of
ExternalLink and Link, i saw the problematic line is that, in ExternalLink
there is no escaping for  signs.

line 159:
tag.put(href, url);
should be as below
tag.put(href, Strings.*replaceAll*(url, , amp;));   (which
was already in the Link.java file)


Regards
Kadir
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

2007-01-23 Thread James McLaughlin


On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.



I would hate to see this method go because I've used it frequently in cases
where I have inner classes and anonymous classes. Fixable with only mild
annoyance, though.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Client-side form validation in Wicket 1.2 or 1.3

2007-01-23 Thread Sean Sullivan


Does Wicket 1.x have the ability to perform client-side form validation?

I'm looking for something similar to Tapestry's client-side validation
feature:

http://tapestry.apache.org/tapestry4.1/usersguide/clientside-validation.html

Cheers,

Sean
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Client-side form validation in Wicket 1.2 or 1.3


no, wicket doesnt provide this out of the box.

there have been some attempts to provide such functionality, i think there
was a project that integrated fvalidate js lib with wicket in wicket-stuff
somewhere.

-igor


On 1/23/07, Sean Sullivan [EMAIL PROTECTED] wrote:


Does Wicket 1.x have the ability to perform client-side form validation?

I'm looking for something similar to Tapestry's client-side validation
feature:


http://tapestry.apache.org/tapestry4.1/usersguide/clientside-validation.html

Cheers,

Sean


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Client-side form validation in Wicket 1.2 or 1.3

2007-01-23 Thread Sean Sullivan


Tapestry does a very good job with client-side form validation. Perhaps
there is code in the Tapestry repository that could be using in Wicket?

BTW, these are the things that I like about form validation in Tapestry 4.1
1)  client-side form validation
2)  CSS class for invalid fields  fieldInvalid
3)  CSS class for missing fields:  fieldMissing

Sean


On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


no, wicket doesnt provide this out of the box.

there have been some attempts to provide such functionality, i think there
was a project that integrated fvalidate js lib with wicket in wicket-stuff
somewhere.

-igor


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

On 1/23/07, James McLaughlin [EMAIL PROTECTED] wrote:

 On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
  getModelValue would have been better than getModelObject yeah. That
  said, imo (and I have stated this before), I think having those
  methods in the first place is distracting, as it doesn't push people
  in the direction of just letting the components and models work
  directly for them.
 

 I would hate to see this method go because I've used it frequently in cases
 where I have inner classes and anonymous classes. Fixable with only mild
 annoyance, though.

It won't go. I'm using it myself as well to be honest. It's just distracting.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Client-side form validation in Wicket 1.2 or 1.3


there are a couple of reasons why we havent done it

wicket's error reporting is very flexible as far as scoping and presentation
goes, it would not be trivial to get client-side and server-side matching,
eg multiple feedback panels with their own message filters, etc, etc.

you cannot perform the entire validation on the client - eg check if
username is available, so you will need a roundtrip back to the server
anyways - so you cannot always show _all_ errors at once - which is
annoying.

i dont think any of the core devs are interested in such a feature, nor has
there been much interest from the users. a patch is always welcome though :)

-igor


On 1/23/07, Sean Sullivan [EMAIL PROTECTED] wrote:



Tapestry does a very good job with client-side form validation. Perhaps
there is code in the Tapestry repository that could be using in Wicket?

BTW, these are the things that I like about form validation in Tapestry
4.1
1)  client-side form validation
2)  CSS class for invalid fields  fieldInvalid
3)  CSS class for missing fields:  fieldMissing

Sean


On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 no, wicket doesnt provide this out of the box.

 there have been some attempts to provide such functionality, i think
 there was a project that integrated fvalidate js lib with wicket in
 wicket-stuff somewhere.

 -igor


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] update propertyModel value to null


Hello,

textarea wicket:id=myString rows=10/textarea

FormComponent myStringComp = new TextArea(myString, new
PropertyModel(this, myString));
myStringComp.add(new AjaxFormComponentUpdatingBehavior(onchange){
   protected void onUpdate(AjaxRequestTarget target) {
  myString
  // do stuff
   }
});

Using ajax, almost everything seems to work. If I clear the textarea and tab
out, the String myString does not change to null or an empty string, it
retains the previous value.

What am I missing?

Thanks,

Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Client-side form validation in Wicket 1.2 or 1.3

It is actually pretty easy to build with Wicket if you want. Like Igor
said, there is a project for this in wicket-stuff, but as the
javascript project died and I (who set up the project) don't want to
support it much as I never actually used it for anything real. Imo
Ajax is a lot more powerful.

However, contributions are more than welcome, and you could try to
rally to get a few people working on this in the form of a
wicket-stuff project.

Eelco


On 1/23/07, Sean Sullivan [EMAIL PROTECTED] wrote:

 Tapestry does a very good job with client-side form validation. Perhaps
 there is code in the Tapestry repository that could be using in Wicket?

 BTW, these are the things that I like about form validation in Tapestry 4.1
 1)  client-side form validation
 2)  CSS class for invalid fields  fieldInvalid
 3)  CSS class for missing fields:  fieldMissing

 Sean



 On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  no, wicket doesnt provide this out of the box.
 
  there have been some attempts to provide such functionality, i think there
 was a project that integrated fvalidate js lib with wicket in wicket-stuff
 somewhere.
 
  -igor
 
 

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null


hmm can you try onblur instead of onchange, dont know if textarea supports
that event

-igor


On 1/23/07, Shawn Tumey [EMAIL PROTECTED] wrote:


Hello,

textarea wicket:id=myString rows=10/textarea

FormComponent myStringComp = new TextArea(myString, new
PropertyModel(this, myString));
myStringComp.add (new AjaxFormComponentUpdatingBehavior(onchange){
protected void onUpdate(AjaxRequestTarget target) {
   myString
   // do stuff
}
});

Using ajax, almost everything seems to work. If I clear the textarea and
tab out, the String myString does not change to null or an empty string, it
retains the previous value.

What am I missing?

Thanks,

Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Dreamweaver

2007-01-23 Thread nilo.de.roock


Wicket makes coding fun again! I don't have a Mac but I do have Dreamweaver
8. It has been a while since I have been using Dreamweaver so I almost
forgot what a superb program it still is. - ( I hope it is not against
Wicket ethics to discuss commercial tool$. )

I would like to ask if anyone else is on this list is using Dreamweaver to
develop and communicate gui designs to users?

If so, has anyone customized and / or extended Dreamweaver to develop and
validate Wicket html?

-- 
View this message in context: 
http://www.nabble.com/-Wicket-user--Dreamweaver-tf3070690.html#a8535117
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Dreamweaver

2007-01-23 Thread nilo.de.roock


Wicket makes coding fun again! I don't have a Mac but I do have Dreamweaver
8. It has been a while since I have been using Dreamweaver so I almost
forgot what a superb program it still is. - ( I hope it is not against
Wicket ethics to discuss commercial tool$. )

I would like to ask if anyone else is on this list is using Dreamweaver to
develop and communicate gui designs to users?

If so, has anyone customized and / or extended Dreamweaver to develop and
validate Wicket html?

kind regards,
nilo de roock
-- 
View this message in context: 
http://www.nabble.com/-Wicket-user--Dreamweaver-tf3070691.html#a8535118
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null


onblur has the same outcome as onchange.

Updates to myString that grow it, or shrink it work fine as long as there is
something in the textarea field. Clearing the field retains the previous
value.

BTW, this is using 1.2.4

any other ideas?

On of my coworkers suggested overloading the setMyString method.

To this end, I created:

public void setMyString() {
  this.myString = null;
}

this had no affect.

On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


hmm can you try onblur instead of onchange, dont know if textarea supports
that event

-igor





--
Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] VOTE: IModel and 'model object' name change

With those names I am changing my vote to +1.

 Erik.

Jonathan Locke wrote:
 what do you think of gustav and eelco's IModelLocator / get/setModel idea?

   

-- 
Erik van Oosten
http://day-to-day-stuff.blogspot.com/


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null

Hi Shawn,

Could you check that you have a single, properly nested form element 
in the html? I vaguely remember someone having problems with this.

 Erik.


Shawn Tumey wrote:
 onblur has the same outcome as onchange.

 Updates to myString that grow it, or shrink it work fine as long as 
 there is something in the textarea field. Clearing the field retains 
 the previous value.

 BTW, this is using 1.2.4

 any other ideas?

 On of my coworkers suggested overloading the setMyString method.

 To this end, I created:

 public void setMyString() {
this.myString = null;
 }

 this had no affect.

 On 1/23/07, *Igor Vaynberg* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:

 hmm can you try onblur instead of onchange, dont know if textarea
 supports that event

 -igor




 -- 
 Shawn Tumey
 Cofounder
 MT Web Productions LLC
 www.mtwebproduction.com http://www.mtwebproduction.com
 

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   

-- 
Erik van Oosten
http://day-to-day-stuff.blogspot.com/


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null


Hello Erik,

The form element is there.

Hello Igor,

I will have check with our software architect before I can upgrade to the
1.3x branch. I am moving on to other functionality for the time being.

Thanks to both of you for your assistance.

Any other suggestions?

Regards,

On 1/23/07, Erik van Oosten [EMAIL PROTECTED] wrote:


Hi Shawn,

Could you check that you have a single, properly nested form element
in the html? I vaguely remember someone having problems with this.

 Erik.







--
Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null


use wicket's ajax debug console to see what the url request is
then set a breakpoint in AjaxFormComponentUpdatingBehavior.onEvent and walk
it, see why its not setting the value to null

-igor



On 1/23/07, Shawn Tumey [EMAIL PROTECTED] wrote:


Hello Erik,

The form element is there.

Hello Igor,

I will have check with our software architect before I can upgrade to the
1.3x branch. I am moving on to other functionality for the time being.

Thanks to both of you for your assistance.

Any other suggestions?

Regards,

On 1/23/07, Erik van Oosten  [EMAIL PROTECTED] wrote:

 Hi Shawn,

 Could you check that you have a single, properly nested form element
 in the html? I vaguely remember someone having problems with this.

  Erik.






--
Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Wicket-contrib-javaee 1.0 release

2007-01-23 Thread Filippo Diotalevi

Hi,
   just a quick post to announce that tonight I've released the first
public version of wicket-contrib-javaee (1.0), a module for Wicket
that provides integration with Java EE 5
With wicket-javaee you can use in your wicket pages three annotations
* @EJB
* @PersistenceUnit
* @Resource
This release works with Wicket 1.2.x; a version for Wicket 2 is under
construction.

The release is available at:
https://sourceforge.net/project/showfiles.php?group_id=134391package_id=219263

the documentation is available at:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee

--
Filippo Diotalevi
http://www.diotalevi.com
http://www.jugmilano.it

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] update propertyModel value to null


The input is returning to the server as an empty string .

The field is required, so when the onEvent method checks
   protected final void onEvent(final AjaxRequestTarget target)
   {
   final FormComponent formComponent = getFormComponent();
   boolean callOnUpdate = true;

   try
   {
   formComponent.inputChanged();
   formComponent.validate();
   if (formComponent.hasErrorMessage())
   {
   formComponent.invalid();
   }
   else
   {
   formComponent.valid();
   formComponent.updateModel();
   }
   }
   catch (RuntimeException e)
   {
   callOnUpdate = false;
   onError(target, e);

   }

   if (callOnUpdate)
   {
   onUpdate(target);
   }

   }

the component is set as invalid and the model is not updated.

I am not concerned if the component is valid at this stage of the game, I
simply have other models I need to update based on what is (or is not) in
this component.

I understand what it is doing, but I believe it is a mistake to not update
the model. Especially since onUdate is still being called with the old
unupdated values.

my $.02

Regards,

On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


use wicket's ajax debug console to see what the url request is
then set a breakpoint in AjaxFormComponentUpdatingBehavior.onEvent and
walk it, see why its not setting the value to null

-igor




--
Shawn Tumey
Cofounder
MT Web Productions LLC
www.mtwebproduction.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket-contrib-javaee 1.0 release

2007-01-23 Thread Martijn Dashorst

Congratulations!

Martijn

On 1/23/07, Filippo Diotalevi [EMAIL PROTECTED] wrote:
 Hi,
just a quick post to announce that tonight I've released the first
 public version of wicket-contrib-javaee (1.0), a module for Wicket
 that provides integration with Java EE 5
 With wicket-javaee you can use in your wicket pages three annotations
 * @EJB
 * @PersistenceUnit
 * @Resource
 This release works with Wicket 1.2.x; a version for Wicket 2 is under
 construction.

 The release is available at:
 https://sourceforge.net/project/showfiles.php?group_id=134391package_id=219263

 the documentation is available at:
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee

 --
 Filippo Diotalevi
 http://www.diotalevi.com
 http://www.jugmilano.it

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-- 
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket-contrib-javaee 1.0 release

Good to hear, thanks!

Eelco


On 1/23/07, Filippo Diotalevi [EMAIL PROTECTED] wrote:
 Hi,
just a quick post to announce that tonight I've released the first
 public version of wicket-contrib-javaee (1.0), a module for Wicket
 that provides integration with Java EE 5
 With wicket-javaee you can use in your wicket pages three annotations
 * @EJB
 * @PersistenceUnit
 * @Resource
 This release works with Wicket 1.2.x; a version for Wicket 2 is under
 construction.

 The release is available at:
 https://sourceforge.net/project/showfiles.php?group_id=134391package_id=219263

 the documentation is available at:
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee

 --
 Filippo Diotalevi
 http://www.diotalevi.com
 http://www.jugmilano.it

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] spring integration question

jip i noticed this also. I guess it is something that the commented source
code that is removed from
the page after rendering did or whatever.

Can anybody look at the last thing that got stuck:

http://wicketstuff.org/bamboo/browse/WICKET2X-EXTENSIONS-11/test/wicket.extensions.markup.html.tree.TreeTest:testRenderTreePageWithBorder_1

it has something to do with borders and transparent resolving of stuff.
tree child is asked at the page, But the page (which isn't a transparent
resolver) doesn't have that as a child but the border (the transparent) has
it
but that is a child of the page so how does that suppose to work?

johan

On 1/23/07, Frank Bille [EMAIL PROTECTED] wrote:

Now it works here as well. :)

Good job

On 1/23/07, Johan Compagner [EMAIL PROTECTED] wrote:

yes and i rechecked it in.
Because the file you checked in is just plain wrong.
Those extra empty spaces don't make any sense!
Please recheck if it fails again for you and then test why those extra
spaces are in front of every empty line.

So i guess Windows Rules.. others just suck! :)

johan

On 1/23/07, Frank Bille [EMAIL PROTECTED] wrote:

On 1/23/07, Johan Compagner [EMAIL PROTECTED] wrote:

it is strange isn't it
now you fixed it so it works on the server

Hmm.. and it works on my machine as well. Windows Sucks(tm)

Frank

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] DatePicker and ModalWindow

2007-01-23 Thread Scott Swank


I put a DatePicker in a form that is in a ModalWindow.  The DatePicker
rendered below the ModalWindow (z height) and was not active because only
the modal window was active.  Is this anything like a known issue?  I search
the history of this list and the wiki without success.

Thanks,
Scott

--
Scott Swank
reformed mathematician
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] DatePicker and ModalWindow


you have to use css to set a higher zvalue for the datepicker popup

-igor


On 1/23/07, Scott Swank [EMAIL PROTECTED] wrote:


I put a DatePicker in a form that is in a ModalWindow.  The DatePicker
rendered below the ModalWindow (z height) and was not active because only
the modal window was active.  Is this anything like a known issue?  I search
the history of this list and the wiki without success.

Thanks,
Scott

--
Scott Swank
reformed mathematician
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] DatePicker and ModalWindow

2007-01-23 Thread Scott Swank


Note to self: must learn css better.  Thanks.

On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


you have to use css to set a higher zvalue for the datepicker popup

-igor


On 1/23/07, Scott Swank  [EMAIL PROTECTED] wrote:

 I put a DatePicker in a form that is in a ModalWindow.  The DatePicker
 rendered below the ModalWindow (z height) and was not active because only
 the modal window was active.  Is this anything like a known issue?  I search
 the history of this list and the wiki without success.

 Thanks,
 Scott

 --
 Scott Swank
 reformed mathematician

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys - and earn cash

 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user






--
Scott Swank
reformed mathematician
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Dreamweaver

2007-01-23 Thread Otan


Yeah, Wicket made it possible for us to use dreamweaver again for
componentized webpages. Based from my experience, I can't find any usecase
to make a Dreamweaver extensions for Wicket.

On 24/01/07, nilo.de.roock [EMAIL PROTECTED] wrote:



Wicket makes coding fun again! I don't have a Mac but I do have
Dreamweaver
8. It has been a while since I have been using Dreamweaver so I almost
forgot what a superb program it still is. - ( I hope it is not against
Wicket ethics to discuss commercial tool$. )

I would like to ask if anyone else is on this list is using Dreamweaver to
develop and communicate gui designs to users?

If so, has anyone customized and / or extended Dreamweaver to develop and
validate Wicket html?

--
View this message in context:
http://www.nabble.com/-Wicket-user--Dreamweaver-tf3070690.html#a8535117
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Strategy to avoid new instances of pages and panels

2007-01-23 Thread dukejansen



Eelco Hillenius wrote:
 
 Well, every user (session) will use memory, correct. But only to a
 certain limit. Wicket 1.2 holds a couple of page/ versions in a
 session, and Wicket 2.0 by default only holds the current one. So the
 creation of a fresh instance (e.g. a bookmarkable page) will replace
 another one. Hence, how much memory you'll need is a simple function
 of the number of concurrent sessions times the size of your session
 and page(s) in it.
 

How can I instruct Wicket not to maintain the multiple versions of a given
page within the session? I've tried the following but when I dump the
session contents I still see multiple page versions:

getSessionSettings().setMaxPageMaps(1);
getPageSettings().setMaxPageVersions(1);

Am I missing the boat on this entirely?

-Jason
-- 
View this message in context: 
http://www.nabble.com/Strategy-to-avoid-new-instances-of-pages-and-panels-tf2566413.html#a8553452
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket-contrib-javaee 1.0 release

2007-01-23 Thread cowwoc


Any JPA library in the works? Specifically I am looking for a
replacement for wicket-stuff-hibernate-3.0

Gili

Filippo Diotalevi wrote:
 Hi,
just a quick post to announce that tonight I've released the first
 public version of wicket-contrib-javaee (1.0), a module for Wicket
 that provides integration with Java EE 5
 With wicket-javaee you can use in your wicket pages three annotations
 * @EJB
 * @PersistenceUnit
 * @Resource
 This release works with Wicket 1.2.x; a version for Wicket 2 is under
 construction.
 
 The release is available at:
 https://sourceforge.net/project/showfiles.php?group_id=134391package_id=219263
 
 the documentation is available at:
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee
 
 --
 Filippo Diotalevi
 http://www.diotalevi.com
 http://www.jugmilano.it
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



signature.asc
Description: OpenPGP digital signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket-contrib-javaee 1.0 release

2007-01-23 Thread Justin Lee

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

It's just annotations for the most part.  Crank it out.  It would've
been months ago if you'd have just done it when you asked last year.  :)

cowwoc wrote:
   Any JPA library in the works? Specifically I am looking for a
 replacement for wicket-stuff-hibernate-3.0
 
 Gili
 
 Filippo Diotalevi wrote:
 Hi,
just a quick post to announce that tonight I've released the first
 public version of wicket-contrib-javaee (1.0), a module for Wicket
 that provides integration with Java EE 5
 With wicket-javaee you can use in your wicket pages three annotations
 * @EJB
 * @PersistenceUnit
 * @Resource
 This release works with Wicket 1.2.x; a version for Wicket 2 is under
 construction.

 The release is available at:
 https://sourceforge.net/project/showfiles.php?group_id=134391package_id=219263

 the documentation is available at:
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee

 --
 Filippo Diotalevi
 http://www.diotalevi.com
 http://www.jugmilano.it

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 
 
 
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

- --
Justin Lee
http://www.antwerkz.com
AIM : evan chooly
Skype : evanchooly
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)

iD8DBQFFtt4AJnQfEGuJ90MRA+2bAJ9H/76NiiQpj3WvSq7m4NciYGD3YQCfUVJa
bQflAcEGYBy+JCTJYe22fb8=
=rrXR
-END PGP SIGNATURE-

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Strategy to avoid new instances of pages and panels

 How can I instruct Wicket not to maintain the multiple versions of a given
 page within the session? I've tried the following but when I dump the
 session contents I still see multiple page versions:

 getSessionSettings().setMaxPageMaps(1);
 getPageSettings().setMaxPageVersions(1);

 Am I missing the boat on this entirely?

Nope, your not missing the point. That stuff needs to be worked on,
see http://issues.apache.org/jira/browse/WICKET-201

I think Johan has been working on it recently. Don't know how far he got yet.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Strategy to avoid new instances of pages and panels

you do realize that by doing this you are completely killing the back button
support in your app

-igor

On 1/23/07, dukejansen [EMAIL PROTECTED] wrote:

Eelco Hillenius wrote:

Well, every user (session) will use memory, correct. But only to a
certain limit. Wicket 1.2 holds a couple of page/ versions in a
session, and Wicket 2.0 by default only holds the current one. So the
creation of a fresh instance (e.g. a bookmarkable page) will replace
another one. Hence, how much memory you'll need is a simple function
of the number of concurrent sessions times the size of your session
and page(s) in it.

How can I instruct Wicket not to maintain the multiple versions of a given
page within the session? I've tried the following but when I dump the
session contents I still see multiple page versions:

getSessionSettings().setMaxPageMaps(1);
getPageSettings().setMaxPageVersions(1);

Am I missing the boat on this entirely?

-Jason
--
View this message in context:
http://www.nabble.com/Strategy-to-avoid-new-instances-of-pages-and-panels-tf2566413.html#a8553452
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Strategy to avoid new instances of pages and panels