Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Igor Vaynberg
+1 to do it now. if this does affect 1.2 only interfaces a lot then we
should do this before we actually release those interfaces into the
wild.

-Igor
On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote:
Currently almost all our interfaces that makes the output or Response writing code are using Stringsas parameters or return typesI would like to change all those methods to use Charsequence because this would mean that
we don't have to do toString() every where and just passing directly the buffer that was madeThis will greatly reduce String char array copies.This does mean that for example:Response.write(String) - 
Response.write(CharSequence)andprotected final void replaceComponentTagBody(final MarkupStream markupStream,   final ComponentTag tag, final String body)protected final void replaceComponentTagBody(final MarkupStream markupStream,
   final ComponentTag tag, final CharSequence body)for calling methods nothing will really change because the String maps on its interface.Only when users have implemented such a method they should also convert 
so for the above replaceComponentTagBody this is not a problem because it is final anywayBut for Response.write() subclasses should also be refactored.Don't know currently yet how many overridable methods really would be affected.
But it could enhance performance quite a bit.Many of the interfaces that would affected are 1.2 only interfaces so if we change them nowthose interfaces never made it to a final version.So what should we do:
[ ] do it in 1.2[ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again)[ ] never do it.johan





[Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Johan Compagner
Currently almost all our interfaces that makes the output or Response writing code are using Stringsas parameters or return typesI would like to change all those methods to use Charsequence because this would mean that
we don't have to do toString() every where and just passing directly the buffer that was madeThis will greatly reduce String char array copies.This does mean that for example:Response.write(String) - 
Response.write(CharSequence)andprotected final void replaceComponentTagBody(final MarkupStream markupStream,   final ComponentTag tag, final String body)protected final void replaceComponentTagBody(final MarkupStream markupStream,
   final ComponentTag tag, final CharSequence body)for calling methods nothing will really change because the String maps on its interface.Only when users have implemented such a method they should also convert 
so for the above replaceComponentTagBody this is not a problem because it is final anywayBut for Response.write() subclasses should also be refactored.Don't know currently yet how many overridable methods really would be affected.
But it could enhance performance quite a bit.Many of the interfaces that would affected are 1.2 only interfaces so if we change them nowthose interfaces never made it to a final version.So what should we do:
[ ] do it in 1.2[ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again)[ ] never do it.johan


Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Johan Compagner
if it is it is a final methodso it doesn't matter it can only be called onso calling it with the same code that is a string just compiles fineand you can't override it (that would be a problem because then they also need to change the signature)
johanOn 4/1/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
+1 for now. For all new 1.2 interfaces and methods and for internalmethods (incl. pre 1.2).Did we add replaceComponentTagBody in 1.2? If not, that should not(yet) be changed. Especially as I can imagine that this function is
used by some users.JuergenOn 4/1/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 to do it now. if this does affect 1.2 only interfaces a lot then we
 should do this before we actually release those interfaces into the wild.-Igor On 4/1/06, Johan Compagner [EMAIL PROTECTED]
 wrote:   Currently almost all our interfaces that makes the output or Response writing code are using Strings  as parameters or return types   I would like to change all those methods to use Charsequence because this
 would mean that  we don't have to do toString() every where and just passing directly the buffer that was made  This will greatly reduce String char array copies.   This does mean that for example:
   Response.write(String) - Response.write(CharSequence)   and   protected final void replaceComponentTagBody(final MarkupStream markupStream,
  final ComponentTag tag, final String body)   protected final void replaceComponentTagBody(final MarkupStream markupStream,  final ComponentTag tag, final CharSequence body)
   for calling methods nothing will really change because the String maps on its interface.   Only when users have implemented such a method they should also convert
  so for the above replaceComponentTagBody this is not a problem because it is final anyway   But for Response.write() subclasses should also be refactored.  
  Don't know currently yet how many overridable methods really would be affected.  But it could enhance performance quite a bit.   Many of the interfaces that would affected are 
1.2 only interfaces so if we change them now  those interfaces never made it to a final version.   So what should we do:   [ ] do it in 1.2  [ ] do it in 
2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again)  [ ] never do it.johan  
---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Juergen Donnerstag
+1 for now. For all new 1.2 interfaces and methods and for internal
methods (incl. pre 1.2).
Did we add replaceComponentTagBody in 1.2? If not, that should not
(yet) be changed. Especially as I can imagine that this function is
used by some users.

Juergen

On 4/1/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 +1 to do it now. if this does affect 1.2 only interfaces a lot then we
 should do this before we actually release those interfaces into the wild.

  -Igor



 On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote:
 
  Currently almost all our interfaces that makes the output or Response
 writing code are using Strings
  as parameters or return types
 
  I would like to change all those methods to use Charsequence because this
 would mean that
  we don't have to do toString() every where and just passing directly the
 buffer that was made
  This will greatly reduce String char array copies.
 
  This does mean that for example:
 
  Response.write(String) - Response.write(CharSequence)
 
  and
 
  protected final void replaceComponentTagBody(final MarkupStream
 markupStream,
  final ComponentTag tag, final String body)
 
  protected final void replaceComponentTagBody(final MarkupStream
 markupStream,
  final ComponentTag tag, final CharSequence body)
 
  for calling methods nothing will really change because the String maps on
 its interface.
 
  Only when users have implemented such a method they should also convert
  so for the above replaceComponentTagBody this is not a problem because it
 is final anyway
 
  But for Response.write() subclasses should also be refactored.
 
 
  Don't know currently yet how many overridable methods really would be
 affected.
  But it could enhance performance quite a bit.
 
  Many of the interfaces that would affected are 1.2 only interfaces so if
 we change them now
  those interfaces never made it to a final version.
 
  So what should we do:
 
  [ ] do it in 1.2
  [ ] do it in 2.0/1.3 with another big refactor? (then interfaces
 introduced in 1.2 will change again)
  [ ] never do it.
 
 
  johan
 
 




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Eelco Hillenius
+1 for now.

Eelco


On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote:
 Currently almost all our interfaces that makes the output or Response
 writing code are using Strings
 as parameters or return types

 I would like to change all those methods to use Charsequence because this
 would mean that
 we don't have to do toString() every where and just passing directly the
 buffer that was made
 This will greatly reduce String char array copies.

 This does mean that for example:

 Response.write(String) - Response.write(CharSequence)

 and

 protected final void replaceComponentTagBody(final MarkupStream
 markupStream,
 final ComponentTag tag, final String body)

 protected final void replaceComponentTagBody(final MarkupStream
 markupStream,
 final ComponentTag tag, final CharSequence body)

 for calling methods nothing will really change because the String maps on
 its interface.

 Only when users have implemented such a method they should also convert
 so for the above replaceComponentTagBody this is not a problem because it is
 final anyway

 But for Response.write() subclasses should also be refactored.


 Don't know currently yet how many overridable methods really would be
 affected.
 But it could enhance performance quite a bit.

 Many of the interfaces that would affected are 1.2 only interfaces so if we
 change them now
 those interfaces never made it to a final version.

 So what should we do:

 [ ] do it in 1.2
 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced
 in 1.2 will change again)
 [ ] never do it.

 johan




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Martijn Dashorst
+1, not breaking existing 1.1 api's.MartijnOn 4/1/06, Eelco Hillenius [EMAIL PROTECTED]
 wrote:+1 for now.EelcoOn 4/1/06, Johan Compagner 
[EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this
 would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example:
 Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body)
 protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on
 its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway
 But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit.
 Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do:
 [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it. johan---
This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-- Wicket 1.2 is coming! Write Ajax applications without touching _javascript_!-- http://wicketframework.org


Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..

2006-04-01 Thread Johan Compagner
I think i have it all in now.There isn't much outside used api touched because if i just look what lines i needed to change over all the contrib libs (didn't check those in yet)it where only a very few and it was just adding toString() or changing String to CharSequence.
And also another project iridium (topicus) just compiles it doesn't complain at allI think this is because i just stopped at one point and that are 2 methods that could be a CharSequence return type but i kept them as strings
(FormComponent.getValue() and Component.getModelObjectAsString())Because that did break to much so i didn't alter themjohanOn 4/1/06, Eelco Hillenius
 [EMAIL PROTECTED] wrote:
+1 for now.EelcoOn 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response
 writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the
 buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence)
 and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream
 markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert
 so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be
 affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version.
 So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it.
 johan---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user