wicket generics

[Igor Vaynberg]

so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design

class component {
  public void setmodel(imodel? model) {...}
  public imodel? getmodel();
}

that is all good until you want to have a generified subclass eg a listitem:

class listitemt extends component {
  public imodelt getmodel() { return (imodelt)super.getmodel(); }
== works like a charm
  public void setmodel(imodelt model) {..} == woops, compilation error

Name clash: The method setModel(IModelT) of type ListItemT has the
same erasure as
 setModel(IModel?) of type MarkupContainer but does not override it

unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(

class listitemt extends component {
  public imodelt getmodel(..);
  public void setmodel(imodel? model);
}

looks half baked and broken by design

i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.

so as far as i can see, and this is only my opinion, our options are:

continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple drop-in/upgrade/whatever

thoughts and ideas?

-igor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Peter Ertl]

 +1 for do it right, no matter if the api breaks or not


Am 07.06.2008 um 09:20 schrieb Igor Vaynberg:


so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design

class component {
 public void setmodel(imodel? model) {...}
 public imodel? getmodel();
}

that is all good until you want to have a generified subclass eg a  
listitem:


class listitemt extends component {
 public imodelt getmodel() { return (imodelt)super.getmodel(); }
== works like a charm
 public void setmodel(imodelt model) {..} == woops, compilation  
error


Name clash: The method setModel(IModelT) of type ListItemT has the
same erasure as
setModel(IModel?) of type MarkupContainer but does not override it

unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(

class listitemt extends component {
 public imodelt getmodel(..);
 public void setmodel(imodel? model);
}

looks half baked and broken by design

i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.

so as far as i can see, and this is only my opinion, our options are:

continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej  
explain )

attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple drop-in/upgrade/whatever

thoughts and ideas?

-igor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: (Class? extends Page?) casting troubles

[Sebastiaan van Erk]

Zappaterrini, Larry wrote:

Sorry, I should have been more clear about subtype. :) When dealing with
raw types, the raw type is considered a super type of the generic type.
So Bar is a super type of Bar?. Since RawType extends the raw type
Bar, consider it to be a peer of Bar?. When you consider them as
peers, a warning is warranted. The new example you use works due to
erasure. Bar? as declared in source code becomes Bar in byte code. So
the statement becomes:

Bar bar = new RawBar();

Which is perfectly legal. I have found that most of perceived
inconsistencies in Java generics stems  from erasure and sub type
substitution. The golden rule of generics is that the byte code produced
by compiling generics will never produce an invalid cast so long as the
code does not produce any warnings. This causes some things that may
seem intuitive to be illegal.


Thanks for your explanation. I still think it's all rather horrible 
though. Type erasure was a huge mistake if you ask me. Two questions for 
you though...


1) Can you come up with an example where assigning a Foo? extends Bar 
to a Foo? extends Bar? causes an invalid cast? (So I can understand 
why this intuitive seeming assignment is illegal).


2) How do you get rid of the warning in ClassFoo clazz = Foo.class 
without using Class?? Because it would seem strange if there is no 
warning free way to use a certain language construct...


Regards,
Sebastiaan


-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 4:16 PM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Zappaterrini, Larry wrote:

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.


I guess it depends on the definition of subtype. It is at least the case

that the following assignment compiles without warnings (without 
warnings about unchecked casts):


   Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(


Regards,
Sebastiaan




-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends

(page of

anything)).

I'm not so sure.

There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype

of

Bar?

But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 

IS CAUSING ONE HALF OF ALL OUR HEADACHES

(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK

-

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 

compiler chokes on this.

ISSUE 2: The class literal of a generic type returns a class of a raw



type.  Thus Foo.class return ClassFoo. This is also really messed
up, 

because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you



type this in eclipse:

x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this,
see 
also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 

So what the heck is the proper type for the class literal??? I
couldn't 

find any!

Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo

of
(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan








__

The information contained in this message is proprietary and/or
confidential. If you are not the 

intended recipient, please: (i) delete the message and all copies;
(ii) do not disclose, 

distribute or use the message in any manner; and (iii) notify the
sender immediately. In addition, 

please be aware that any message addressed to our domain is subject to
archiving and review by 

persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL 

Re: wicket generics

[Jan Kriesten]

hi igor,

that's a mess. :-(

i would go for decoupling component/model for 1.4 - that makes a clean cut for 
the api towards generics. everything else is just half-baked.


my 2c, --- jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Gwyn Evans]

On Sat, Jun 7, 2008 at 8:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 thoughts and ideas?

Is there much else apart from Generic's that's in 1.4 that would
benefit from a release 'sooner' rather than 'later'?

I know the intentions's not to have it much different, but not
changing 1.3's overridden that, so arent't there were a few things,
such as making org.apache.wicket.MarkupContainer#getMarkupType
overridable allowing non-HTML pages, which might be worth considering?
 That's been my reason for using 1.4 so I know about that, but are
there other things?

/Gwyn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Sebastiaan van Erk]

I'm +1 for trying to decouple model from component, and if it takes 
longer then so be it.


I'm pretty convinced that the problem is the 1-1 model-component 
coupling and that generics only pointed out this problem.


Regards,
Sebastiaan

Igor Vaynberg wrote:

so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design

class component {
  public void setmodel(imodel? model) {...}
  public imodel? getmodel();
}

that is all good until you want to have a generified subclass eg a listitem:

class listitemt extends component {
  public imodelt getmodel() { return (imodelt)super.getmodel(); }
== works like a charm
  public void setmodel(imodelt model) {..} == woops, compilation error

Name clash: The method setModel(IModelT) of type ListItemT has the
same erasure as
 setModel(IModel?) of type MarkupContainer but does not override it

unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(

class listitemt extends component {
  public imodelt getmodel(..);
  public void setmodel(imodel? model);
}

looks half baked and broken by design

i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.

so as far as i can see, and this is only my opinion, our options are:

continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple drop-in/upgrade/whatever

thoughts and ideas?

-igor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

Re: wicket generics

[Matej Knopp]

The decoupling doesn't have to be extremely painful. We could leave
support for the default slot in component, something like this:

class Component {
 protected void setDefaultModel(IModel? model);
 protected IModel? getDefaultModel();
}

class MyComponentT extends Component {
  public void setModel(IModelT model); // note - no clashes, method
name is different
 public IModelT getModel();
}

This would solve some problems with decoupling model, such as that
setModel has to do some magic (wrapping, etc). Also given the way
default model slot is currently implemented this has not bigger memory
footprint than not having the slot at all.

-Matej

On Sat, Jun 7, 2008 at 12:17 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
 I'm +1 for trying to decouple model from component, and if it takes longer
 then so be it.

 I'm pretty convinced that the problem is the 1-1 model-component coupling
 and that generics only pointed out this problem.

 Regards,
 Sebastiaan

 Igor Vaynberg wrote:

 so i tried to remove the generic type from component in
 sandbox/ivaynberg/wicket-generics branch and ran into what i think is
 a deal breaker for this design

 class component {
  public void setmodel(imodel? model) {...}
  public imodel? getmodel();
 }

 that is all good until you want to have a generified subclass eg a
 listitem:

 class listitemt extends component {
  public imodelt getmodel() { return (imodelt)super.getmodel(); }
 == works like a charm
  public void setmodel(imodelt model) {..} == woops, compilation error

 Name clash: The method setModel(IModelT) of type ListItemT has the
 same erasure as
  setModel(IModel?) of type MarkupContainer but does not override it

 unfortunately the error makes sense and there is no way around it.
 same goes for setmodelobject(). i think this makes this design variant
 pretty useless. as long as we have the model coupled to component i
 dont see a clean way of doing this :(

 class listitemt extends component {
  public imodelt getmodel(..);
  public void setmodel(imodel? model);
 }

 looks half baked and broken by design

 i would almost reconsider 1.4 and its scope and opt to include a model
 decoupling (however and if that is possible) refactor in it. otherwise
 i fear we will break the whole generics model again in 1.5 and users
 will have to relearn how to use them with wicket.

 so as far as i can see, and this is only my opinion, our options are:

 continue 1.4 as it is now with fully typed components
 remove component type but make the api ugly ( i will let matej explain )
 attempt to fix 1.4 by decoupling model from component - 1.4 takes a
 lot longer and is not a simple drop-in/upgrade/whatever

 thoughts and ideas?

 -igor

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: users, please give us your opinion: what is your take on generics with Wicket

[Ivo van Dongen]

1) Generifying* Wicket
   [ X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.

2) How strongly do you feel about your choice above?
   [ X ] I might rethink upgrading if my choice doesn't win.

  


Regards,
Ivo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Timo Rantalaiho]

Hi Igor and others,

Great that you tried that out in practice!

On Sat, 07 Jun 2008, Igor Vaynberg wrote:
 class component {
   public void setmodel(imodel? model) {...}
   public imodel? getmodel();
 }

I was earlier trying out this variant:

public class Component {
public T Component setModel(final IModelT model) { ... }
public IModel? getModel() { ... }
public Object getModelObject() { ... }
public T Component setModelObject(final T object) { ... }
}

and as far as I can tell, this does not inhibit the same
problem with generified subclasses. E.g. this works

public class ListItemT extends WebMarkupContainer { 
@SuppressWarnings({unchecked})
@Override
public IModelT getModel()
{
return (IModelT) super.getModel();
}

@Override
public T ListItem setModel(IModelT model)
{
return (ListItem) super.setModel(model);
}

@SuppressWarnings({unchecked})
@Override
public T getModelObject()
{
return (T) super.getModelObject();
}

@Override
public T Component setModelObject(T object)
{
return super.setModelObject(object);
}
...
}

The unchecked cast warning when casting Object to T in 
getModelObject() is a bummer, but then again I didn't 
even think that getModelObject() would be overriden in 
the generified subclasses (I don't consider needing to do 
Foo foo = (Foo) getModelObject() a problem). The same 
goes for getModel().

 i would almost reconsider 1.4 and its scope and opt to include a model
 decoupling (however and if that is possible) refactor in it. otherwise
 i fear we will break the whole generics model again in 1.5 and users
 will have to relearn how to use them with wicket.

Model decoupling would mean removing the default IModel of
Component, that was discussed this week, right?

It seems like a great idea [1] on the longer run, but as far as
I understand, the idea was to
- drop 1.3 support when 1.4 comes out
- offer 1.4 as a drop-in replacement (except for Java 5
  requirement) for 1.3 users
- leave API breaks for 1.5

...and I don't see how the decoupling could happen without 
a big API break. 

So then it would effectively mean continuing Wicket 1.3 (and
Java 1.4) support for longer?
 
 so as far as i can see, and this is only my opinion, our options are:
 
 continue 1.4 as it is now with fully typed components
 remove component type but make the api ugly ( i will let matej explain )

Matej, please explain :)

 attempt to fix 1.4 by decoupling model from component - 1.4 takes a
 lot longer and is not a simple drop-in/upgrade/whatever

Yet another option would be to address this only in 1.5, and
drop Component and IModel generics from 1.4 altogether.

Best wishes,
Timo


[1] The Component class has a lot of responsibilities, so
removing any of them, such as the default model handling, is
a step to the right direction.

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

always call method

[Mathias P.W Nilsson]

Hi!

Is there a way to always call a method in a wicket page even if the browser
back button is pressed?
-- 
View this message in context: 
http://www.nabble.com/always-call-method-tp17708799p17708799.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

YUI DatePicker javascript inefficiency

[Martin Makundi]

Hi!

I have a table with sevearal rows and each row has a couple of YUI
datepickers (org.apache.wicket.extensions.yui.calendar.DatePicker).

I was wondering why the page loads very slowly and then I had a look
at the web page source code.

The web page is bloated with repeatedly submitted YUI javascript -
most of it is just repetition with very minor differences.

Does anyone know how this particular javascript can be optimized and
if it has been done before somewhere? Or would you recommend some
alternative?

**
Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: always call method

[Timo Rantalaiho]

On Sat, 07 Jun 2008, Mathias P.W Nilsson wrote:
 Is there a way to always call a method in a wicket page even if the browser
 back button is pressed?

Yes, by putting no-cache headers in the previous page the
browser will request it again when you go back there.

Without explicitly disabling caching it will depend on the
caching settings of the browser.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Lightweight generic busy indicator

[Martin Makundi]

Hi!

I am trying to maneuvre a lightweight gmail-style busy indicator to
stay in place whenever I click an operative button.

The script seems to work fine with regular submit buttons, but I have
not found a proper way to reset the indicator in context with ajax
buttons and links.

Is there an event I could bind this to, or do I have to push some
javascript from the server side / tweak the wicket-ajax.js? It would
be pretty nice if I could just overload/hook-to something on
javascript level.

Here is my code:

style type=text/css
#busysign {
  display: none;
  float: right;
  background: red;
  margin-top: 5px;
  margin-right: 5px;
  z-index: 1000;
  width: 200;
  font-weight: bold;
  text-align: center;
  font-size: 1.3em;
}
/style
script type=text/javascript
  window.onload = setupFunc;

  function setupFunc() {
document.getElementsByTagName('body')[0].onclick = clickFunc;
  }

  function clickFunc(eventData) {
var clickedElement = (window.event) ? event.srcElement : eventData.target;
if (clickedElement.tagName == 'BUTTON'
  || (clickedElement.tagName == 'INPUT'  (clickedElement.type ==
'button' || clickedElement.type == 'submit'))) {
  document.getElementById('busysign').style.display ='inline';
}
  }
/script


I would equally well appreciate if you had some alternative generic
lightweight solution :)


**
Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Igor Vaynberg]

i dont think listitem#setmodel is restricted in your example.to T in ListItemT

public T ListItem setModel(IModelT model)

the first T hides the T of ListItemT so you might as well have
said X setModel(IModelX model)

-igor

On Sat, Jun 7, 2008 at 4:48 AM, Timo Rantalaiho [EMAIL PROTECTED] wrote:
 Hi Igor and others,

 Great that you tried that out in practice!

 On Sat, 07 Jun 2008, Igor Vaynberg wrote:
 class component {
   public void setmodel(imodel? model) {...}
   public imodel? getmodel();
 }

 I was earlier trying out this variant:

 public class Component {
public T Component setModel(final IModelT model) { ... }
public IModel? getModel() { ... }
public Object getModelObject() { ... }
public T Component setModelObject(final T object) { ... }
 }

 and as far as I can tell, this does not inhibit the same
 problem with generified subclasses. E.g. this works

 public class ListItemT extends WebMarkupContainer {
@SuppressWarnings({unchecked})
@Override
public IModelT getModel()
{
return (IModelT) super.getModel();
}

@Override
public T ListItem setModel(IModelT model)
{
return (ListItem) super.setModel(model);
}

@SuppressWarnings({unchecked})
@Override
public T getModelObject()
{
return (T) super.getModelObject();
}

@Override
public T Component setModelObject(T object)
{
return super.setModelObject(object);
}
 ...
 }

 The unchecked cast warning when casting Object to T in
 getModelObject() is a bummer, but then again I didn't
 even think that getModelObject() would be overriden in
 the generified subclasses (I don't consider needing to do
 Foo foo = (Foo) getModelObject() a problem). The same
 goes for getModel().

 i would almost reconsider 1.4 and its scope and opt to include a model
 decoupling (however and if that is possible) refactor in it. otherwise
 i fear we will break the whole generics model again in 1.5 and users
 will have to relearn how to use them with wicket.

 Model decoupling would mean removing the default IModel of
 Component, that was discussed this week, right?

 It seems like a great idea [1] on the longer run, but as far as
 I understand, the idea was to
 - drop 1.3 support when 1.4 comes out
 - offer 1.4 as a drop-in replacement (except for Java 5
  requirement) for 1.3 users
 - leave API breaks for 1.5

 ...and I don't see how the decoupling could happen without
 a big API break.

 So then it would effectively mean continuing Wicket 1.3 (and
 Java 1.4) support for longer?

 so as far as i can see, and this is only my opinion, our options are:

 continue 1.4 as it is now with fully typed components
 remove component type but make the api ugly ( i will let matej explain )

 Matej, please explain :)

 attempt to fix 1.4 by decoupling model from component - 1.4 takes a
 lot longer and is not a simple drop-in/upgrade/whatever

 Yet another option would be to address this only in 1.5, and
 drop Component and IModel generics from 1.4 altogether.

 Best wishes,
 Timo


 [1] The Component class has a lot of responsibilities, so
 removing any of them, such as the default model handling, is
 a step to the right direction.

 --
 Timo Rantalaiho
 Reaktor Innovations OyURL: http://www.ri.fi/ 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Lightweight generic busy indicator

[Igor Vaynberg]

wicket supports global javascript event handlers for this. either
search the list or look inside wicet-ajax.js, i cant recall them off
the top of my head.

-igor

On Sat, Jun 7, 2008 at 8:59 AM, Martin Makundi
[EMAIL PROTECTED] wrote:
 Hi!

 I am trying to maneuvre a lightweight gmail-style busy indicator to
 stay in place whenever I click an operative button.

 The script seems to work fine with regular submit buttons, but I have
 not found a proper way to reset the indicator in context with ajax
 buttons and links.

 Is there an event I could bind this to, or do I have to push some
 javascript from the server side / tweak the wicket-ajax.js? It would
 be pretty nice if I could just overload/hook-to something on
 javascript level.

 Here is my code:

 style type=text/css
 #busysign {
  display: none;
  float: right;
  background: red;
  margin-top: 5px;
  margin-right: 5px;
  z-index: 1000;
  width: 200;
  font-weight: bold;
  text-align: center;
  font-size: 1.3em;
 }
 /style
 script type=text/javascript
  window.onload = setupFunc;

  function setupFunc() {
document.getElementsByTagName('body')[0].onclick = clickFunc;
  }

  function clickFunc(eventData) {
var clickedElement = (window.event) ? event.srcElement : eventData.target;
if (clickedElement.tagName == 'BUTTON'
  || (clickedElement.tagName == 'INPUT'  (clickedElement.type ==
 'button' || clickedElement.type == 'submit'))) {
  document.getElementById('busysign').style.display ='inline';
}
  }
 /script


 I would equally well appreciate if you had some alternative generic
 lightweight solution :)


 **
 Martin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Status of Wicket and Groovy?

[Ashley Aitken]

Howdy All,

There's a question at the end of this long intro:

I've been evaluating and comparing a number of Web frameworks again,  
particularly at this time Wicket (which I have looked at previously  
and tried out) and Django (which I am new to but comes highly  
recommended).


I very much like the way Wicket has a complete (yes, I think complete  
is a good description) separation of the (X)HTML and Java code. It's  
fantastic when you want graphic designers to design the pages (with  
dummy data as well).


I'm over the idea of using a complex template language, even the  
simplified (presentation only) template language used in Django (so I  
don't wish to go near JSF and I'm even a little negative on Tapestry  
which has a similar minimal template language).


Django on the other hand use the dynamic language Python which makes  
writing apps easier (and shorter). It also seems to make it very easy  
to create more powerful applications by combining smaller  
applications (e.g. it includes a powerful automatic CRUD interface).


I know Wicket makes it very easy to develop components and there are  
some component libraries (e.g. Wicket Stuff) but it doesn't seem like  
there are as many (high level components) as Django or that they are  
as easy to integrate (that's just my perception).


So when I was looking at the Wikipedia comparison on Web frameworks I  
noticed something. There doesn't seem to be a pull (component-based)  
Web framework that uses a dynamic programming language (like Groovy,  
Ruby or Python).  Grok seems too left field.


Django, RoR and Grails are all push (request-based) Web frameworks  
and, as I mentioned above, use template languages to varying degrees.   
So I was thinking a pull (component-based) Web framework like Wicket  
but using a dynamic language could be a great move.


A quick Google showed me that some work has been done with Groovy  
(wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan.   
However, Kevin seems to have moved on to Seam and wicket-contrib- 
groovy seems to be no longer supported.


From what I saw of WicketBuilder it seems it has a lot of potential  
to make Wicket development more dynamic (with the  
GroovyClassResolver), reduce the code required to write Wicket  
applications, and even make them clearer with no overhead when deployed.


So my question is: what is the status (now and going forward) with  
regards to using Groovy to develop with Wicket?  I know there has been  
much discussion of generifying Wicket but perhaps moving to a dynamic  
language could be an alternative future.


Of course, using Groovy with Wicket wouldn't require the framework  
itself to be implemented in Groovy or even that everyone uses Groovy.   
And, as you all probably know Groovy can easily call an Java class  
library.


So what do people think about Groovy and Wicket?

Cheers,
Ashley.

Some relevant URLs:

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketBuilder
http://www.kgalligan.com/wicketgroovy-setup
http://www.kgalligan.com/wicketgroovy-simplepage
http://bigheadco.blogspot.com/2007/03/wicket-and-groovy.html
http://people.byte-code.com/dpanelli/2008/02/04/groovy-wicket/

--
Ashley Aitken
04 1226-8159 (Mb)
08 9368-5505 (Ph)
Perth, Western Australia
Skype/iChat: MrHatken (GMT + 8hrs!)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: wicket generics

[Timo Rantalaiho]

On Sat, 07 Jun 2008, Igor Vaynberg wrote:
 i dont think listitem#setmodel is restricted in your example.to T in 
 ListItemT
 
 public T ListItem setModel(IModelT model)
 
 the first T hides the T of ListItemT so you might as well have
 said X setModel(IModelX model)

Heh, you're right of course. 

There doesn't seem to be an easy way out, if you want to
bind the type of the component with the type of its model
only in a part of the Component inheritance hierarchy.

I still find loosening the model type checks also in
parametrised subclasses of Component a viable alternative
for 1.4 (with less reuse of type variable names than what
I'm guilty of :)). That is if we want to provide a fairly
compatible alternative for migrating from 1.3.

But on longer term, decoupling IModel from Component might
be the best thing to have come out of this generics episode.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Lightweight generic busy indicator

[Peter Thomas]

On Sat, Jun 7, 2008 at 9:47 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:

 wicket supports global javascript event handlers for this. either
 search the list or look inside wicet-ajax.js, i cant recall them off
 the top of my head.


They are mentioned in this thread:

http://www.nabble.com/Re%3A-ajax-progress-indicator-p17020185.html



 -igor

 On Sat, Jun 7, 2008 at 8:59 AM, Martin Makundi
 [EMAIL PROTECTED] wrote:
  Hi!
 
  I am trying to maneuvre a lightweight gmail-style busy indicator to
  stay in place whenever I click an operative button.
 
  The script seems to work fine with regular submit buttons, but I have
  not found a proper way to reset the indicator in context with ajax
  buttons and links.
 
  Is there an event I could bind this to, or do I have to push some
  javascript from the server side / tweak the wicket-ajax.js? It would
  be pretty nice if I could just overload/hook-to something on
  javascript level.
 
  Here is my code:
 
  style type=text/css
  #busysign {
   display: none;
   float: right;
   background: red;
   margin-top: 5px;
   margin-right: 5px;
   z-index: 1000;
   width: 200;
   font-weight: bold;
   text-align: center;
   font-size: 1.3em;
  }
  /style
  script type=text/javascript
   window.onload = setupFunc;
 
   function setupFunc() {
 document.getElementsByTagName('body')[0].onclick = clickFunc;
   }
 
   function clickFunc(eventData) {
 var clickedElement = (window.event) ? event.srcElement :
 eventData.target;
 if (clickedElement.tagName == 'BUTTON'
   || (clickedElement.tagName == 'INPUT'  (clickedElement.type ==
  'button' || clickedElement.type == 'submit'))) {
   document.getElementById('busysign').style.display ='inline';
 }
   }
  /script
 
 
  I would equally well appreciate if you had some alternative generic
  lightweight solution :)
 
 
  **
  Martin
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: YUI DatePicker javascript inefficiency

[Peter Thomas]

On Sat, Jun 7, 2008 at 7:17 PM, Martin Makundi 
[EMAIL PROTECTED] wrote:

 Hi!

 I have a table with sevearal rows and each row has a couple of YUI
 datepickers (org.apache.wicket.extensions.yui.calendar.DatePicker).

 I was wondering why the page loads very slowly and then I had a look
 at the web page source code.

 The web page is bloated with repeatedly submitted YUI javascript -
 most of it is just repetition with very minor differences.


You could consider rolling your own datepicker component using YUI, I had
some success with this and was also able to factor out some of the
repetitive js into a common *.js file but in my case I don't need
localization at all which the Wicket extensions one is good at.




 Does anyone know how this particular javascript can be optimized and
 if it has been done before somewhere? Or would you recommend some
 alternative?

 **
 Martin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: YUI DatePicker javascript inefficiency

[Martin Makundi]

I haven't been much into javascript, yet ;)

It looks like an easy job for someone who knows what they're doing -
pull out the function name changes as parameters to the methods
instead of hardcoding for each FormComponent.

The main differences are:

initWIDGET123 = function() {
initWIDGET124 = function() {

---

widgetId: WIDGET123,
widgetId: WIDGET124,

---

componentId: WIDGET123,
componentId: WIDGET124,

---

  initWIDGET123();
  initWIDGET124();

---

  wicketCalendarInits.push(initWIDGET123);
  wicketCalendarInits.push(initWIDGET124);

---

Anybody know how to trick this into plain string parameter format?

**
Martin

2008/6/7 Peter Thomas [EMAIL PROTECTED]:
 On Sat, Jun 7, 2008 at 7:17 PM, Martin Makundi 
 [EMAIL PROTECTED] wrote:

 Hi!

 I have a table with sevearal rows and each row has a couple of YUI
 datepickers (org.apache.wicket.extensions.yui.calendar.DatePicker).

 I was wondering why the page loads very slowly and then I had a look
 at the web page source code.

 The web page is bloated with repeatedly submitted YUI javascript -
 most of it is just repetition with very minor differences.


 You could consider rolling your own datepicker component using YUI, I had
 some success with this and was also able to factor out some of the
 repetitive js into a common *.js file but in my case I don't need
 localization at all which the Wicket extensions one is good at.




 Does anyone know how this particular javascript can be optimized and
 if it has been done before somewhere? Or would you recommend some
 alternative?

 **
 Martin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Lightweight generic busy indicator

[Martin Makundi]

Hi!

Did I misunderstand something? I am not a javascript-wizard ;) I could
make it work perfectly with non-ajax buttons and links but it does not
seem to react to wicket ajax buttons.

Here is the script code, pls take a look if there is a blatant bug (I
assumed I do not need to make any modifications onto the server side):

script type=text/javascript
  /*
   * div id=busysignLoading .../div
   */
  window.onload = setupFunc;

  Wicket.Ajax.registerPreCallHandler(showBusysign());
  Wicket.Ajax.registerPostCallHandler(hideBusysign());
  Wicket.Ajax.registerFailureHandler(hideBusysign());

  function setupFunc() {
document.getElementsByTagName('body')[0].onclick = clickFunc;
hideBusysign();
  }

  function hideBusysign() {
document.getElementById('busysign').style.display ='none';
  }

  function showBusysign() {
document.getElementById('busysign').style.display ='inline';
  }

  function clickFunc(eventData) {
var clickedElement = (window.event) ? event.srcElement : eventData.target;
if (clickedElement.tagName == 'BUTTON' || clickedElement.tagName
== 'A' || clickedElement.parentNode.tagName == 'A'
  || (clickedElement.tagName == 'INPUT'  (clickedElement.type ==
'BUTTON' || clickedElement.type == 'SUBMIT'))) {
  showBusysign();
}
  }
/script


**
Martin

2008/6/7 Peter Thomas [EMAIL PROTECTED]:
 On Sat, Jun 7, 2008 at 9:47 PM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:

 wicket supports global javascript event handlers for this. either
 search the list or look inside wicet-ajax.js, i cant recall them off
 the top of my head.


 They are mentioned in this thread:

 http://www.nabble.com/Re%3A-ajax-progress-indicator-p17020185.html



 -igor

 On Sat, Jun 7, 2008 at 8:59 AM, Martin Makundi
 [EMAIL PROTECTED] wrote:
  Hi!
 
  I am trying to maneuvre a lightweight gmail-style busy indicator to
  stay in place whenever I click an operative button.
 
  The script seems to work fine with regular submit buttons, but I have
  not found a proper way to reset the indicator in context with ajax
  buttons and links.
 
  Is there an event I could bind this to, or do I have to push some
  javascript from the server side / tweak the wicket-ajax.js? It would
  be pretty nice if I could just overload/hook-to something on
  javascript level.
 
  Here is my code:
 
  style type=text/css
  #busysign {
   display: none;
   float: right;
   background: red;
   margin-top: 5px;
   margin-right: 5px;
   z-index: 1000;
   width: 200;
   font-weight: bold;
   text-align: center;
   font-size: 1.3em;
  }
  /style
  script type=text/javascript
   window.onload = setupFunc;
 
   function setupFunc() {
 document.getElementsByTagName('body')[0].onclick = clickFunc;
   }
 
   function clickFunc(eventData) {
 var clickedElement = (window.event) ? event.srcElement :
 eventData.target;
 if (clickedElement.tagName == 'BUTTON'
   || (clickedElement.tagName == 'INPUT'  (clickedElement.type ==
  'button' || clickedElement.type == 'submit'))) {
   document.getElementById('busysign').style.display ='inline';
 }
   }
  /script
 
 
  I would equally well appreciate if you had some alternative generic
  lightweight solution :)
 
 
  **
  Martin
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

localized string in session

[Emacs]

Hi!

I've created a custom websession for authentication. 
Is there a way to get a localized string ala getString(key) in this
websession?

The reason why I want to do this is, because I want to create an localized
error message, for
userers, who try to login, before their account is activated (activation
through a link in an email)
so I check the the usergroup this user belongs to, and if he is in the wrong
usergroup, i want to create this message ala this useraccount hasn't been
activated yet! please follow the link in the registration email...

Thanx in advance!

-Hannes
-- 
View this message in context: 
http://www.nabble.com/localized-string-in-session-tp17713276p17713276.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: users, please give us your opinion: what is your take on generics with Wicket

[xiefei]

 [X] Can best be done like currently in the 1.4 branch, where models and 
components are both generified. I care most about the improved static type 
checking generified models and components give Wicket. 
 I am just a little annoyed when a component not having a model causes generics 
warning.
 
 [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and 
up. 
_
MSN 中文网，最新时尚生活资讯，白领聚集门户。
http://cn.msn.com