from:"Stefan Fußenegger"


My suggestions was to actually maintain a minimal JS api in the future. I
don't believe that the very basic utility functions are going to change
between minor versions. So it might be worth thinking about making this API
official. The users would definitely benefit from it - and nobody would have
to write a single line of code. It's just a suggestion, as I think it's at
least worth considering.


igor.vaynberg wrote:
> 
> thats exactly the point. we do not maintain api compatibility of the
> js code, not even between minor versions, so you should not use them
> or depend on them.
> 
> -igor
> 
> On Thu, Jan 15, 2009 at 10:05 AM, Stefan Fußenegger
>  wrote:
>>
>> Even if they are for "wicket's internal use", documentation might be
>> valuable, especially for (wicketstuff) developers who go deeper then
>> regular
>> users. Furthermore, having some basic JS utilities (with documented
>> public
>> API) coming with Wicket would make using Wicket even more fun. I'd bet
>> that
>> a lot of Wicket users implemented Wicket.$('id') or something similar on
>> their own. And I'm not talking about a fully fledged JS framework or
>> library, just some basic stuff to handle common tasks like the whole
>> event
>> stuff or some DOM manipulations. Basically just what's in place already
>> but
>> kept secret for "internal use only".
>>
>> Maybe that's a candidate for the Wicket 1.5 wishlist ...
>>
>>
>> igor.vaynberg wrote:
>>>
>>> On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger
>>>  wrote:
>>>>
>>>> I knew it was pseudo code. With "JS library" I meant the stuff
>>>> contained
>>>> in
>>>> wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.
>>>
>>> those are for wicket's internal use. dont touch :)
>>>
>>>> with replacing border, you meant the server-side concept of a Border,
>>>> right?
>>>> I was talking more of a html related concept (bad description, sorry),
>>>> where
>>>> a border is some markup surrounding some other markup. The later should
>>>> be
>>>> kept untouched by the update. I think it shouldn't be to difficult to
>>>> get
>>>> a
>>>> DOM node by id, remove it or move it somewhere else temporarily, insert
>>>> the
>>>> ajax-retrieve stuff, move the DOM node back to where it was. If the
>>>> implementation is as simple as this, it would be a feature worth
>>>> adding,
>>>> wouldn't it?
>>>
>>> javascript implementation is easy, it is the serverside declaration
>>> and invocation that would be confusing. you are welcome to prototype
>>> it if you want to pursue it further.
>>>
>>> -igor
>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
>>>>>  wrote:
>>>>>>
>>>>>> Thanks, I'll go for the suggested JS.Is there any documentation of
>>>>>> the
>>>>>> Wicket
>>>>>> JavaScript library available somewhere?
>>>>>
>>>>> there is no wicket js library, what i gave you was pseudocode.
>>>>>
>>>>>> However, wouldn't be replacing borders (i.e. keeping parts of the
>>>>>> hierarchy)
>>>>>> be a nice feature? I'd add a ticket if you agree.
>>>>>
>>>>> you can replace borders already, the problem here relates to the
>>>>> timing of client-server interaction. because you are validating while
>>>>> the user is typing the serverside often gets the value that is out of
>>>>> date since the user types faster then you can send requests to the
>>>>> server. this means that when repainting the component on the
>>>>> serverside there is a good chance you will repaint it with the wrong
>>>>> value.
>>>>>
>>>>> currently there is no way to tell a form component to repaint but not
>>>>> update its value attribute, and this is not always possible anyways.
>>>>>
>>>>> -igor
>>>>>
>>>>>>
>>>>>> Regards, Stefan
>>>>>>
>>>>>>
>>>>>> igor.vaynberg wrote:
>>>>

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes


Even if they are for "wicket's internal use", documentation might be
valuable, especially for (wicketstuff) developers who go deeper then regular
users. Furthermore, having some basic JS utilities (with documented public
API) coming with Wicket would make using Wicket even more fun. I'd bet that
a lot of Wicket users implemented Wicket.$('id') or something similar on
their own. And I'm not talking about a fully fledged JS framework or
library, just some basic stuff to handle common tasks like the whole event
stuff or some DOM manipulations. Basically just what's in place already but
kept secret for "internal use only".

Maybe that's a candidate for the Wicket 1.5 wishlist ...


igor.vaynberg wrote:
> 
> On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger
>  wrote:
>>
>> I knew it was pseudo code. With "JS library" I meant the stuff contained
>> in
>> wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.
> 
> those are for wicket's internal use. dont touch :)
> 
>> with replacing border, you meant the server-side concept of a Border,
>> right?
>> I was talking more of a html related concept (bad description, sorry),
>> where
>> a border is some markup surrounding some other markup. The later should
>> be
>> kept untouched by the update. I think it shouldn't be to difficult to get
>> a
>> DOM node by id, remove it or move it somewhere else temporarily, insert
>> the
>> ajax-retrieve stuff, move the DOM node back to where it was. If the
>> implementation is as simple as this, it would be a feature worth adding,
>> wouldn't it?
> 
> javascript implementation is easy, it is the serverside declaration
> and invocation that would be confusing. you are welcome to prototype
> it if you want to pursue it further.
> 
> -igor
> 
>>
>> Regards
>>
>>
>> igor.vaynberg wrote:
>>>
>>> On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
>>>  wrote:
>>>>
>>>> Thanks, I'll go for the suggested JS.Is there any documentation of the
>>>> Wicket
>>>> JavaScript library available somewhere?
>>>
>>> there is no wicket js library, what i gave you was pseudocode.
>>>
>>>> However, wouldn't be replacing borders (i.e. keeping parts of the
>>>> hierarchy)
>>>> be a nice feature? I'd add a ticket if you agree.
>>>
>>> you can replace borders already, the problem here relates to the
>>> timing of client-server interaction. because you are validating while
>>> the user is typing the serverside often gets the value that is out of
>>> date since the user types faster then you can send requests to the
>>> server. this means that when repainting the component on the
>>> serverside there is a good chance you will repaint it with the wrong
>>> value.
>>>
>>> currently there is no way to tell a form component to repaint but not
>>> update its value attribute, and this is not always possible anyways.
>>>
>>> -igor
>>>
>>>>
>>>> Regards, Stefan
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> the way to do this is to have the div be output there without
>>>>> class="error" and to append the class to it via
>>>>> ajaxrequesttarget.appendjavascript("$(divid).addclass('error');");
>>>>>
>>>>> that way you do not need to repaint the input tag which is the
>>>>> problematic part for your usecase.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
>>>>>  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> My HTML looks similar to this:
>>>>>>
>>>>>> Foo
>>>>>>
>>>>>> I want to validate the contents of the field as soon as the user
>>>>>> starts
>>>>>> typing. If there is an error, the html should become:
>>>>>>
>>>>>> There was an errorFoo>>>>> type="text"
>>>>>> />
>>>>>>
>>>>>> However, if I add the whole hierarchy to the AjaxRequestTarget, the
>>>>>> changes
>>>>>> in the text field get lost (Which results in quite weired typing
>>>>>> behavior).
>>>>>>
>>>>>

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes


I knew it was pseudo code. With "JS library" I meant the stuff contained in
wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js.

with replacing border, you meant the server-side concept of a Border, right?
I was talking more of a html related concept (bad description, sorry), where
a border is some markup surrounding some other markup. The later should be
kept untouched by the update. I think it shouldn't be to difficult to get a
DOM node by id, remove it or move it somewhere else temporarily, insert the
ajax-retrieve stuff, move the DOM node back to where it was. If the
implementation is as simple as this, it would be a feature worth adding,
wouldn't it?

Regards 


igor.vaynberg wrote:
> 
> On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger
>  wrote:
>>
>> Thanks, I'll go for the suggested JS.Is there any documentation of the
>> Wicket
>> JavaScript library available somewhere?
> 
> there is no wicket js library, what i gave you was pseudocode.
> 
>> However, wouldn't be replacing borders (i.e. keeping parts of the
>> hierarchy)
>> be a nice feature? I'd add a ticket if you agree.
> 
> you can replace borders already, the problem here relates to the
> timing of client-server interaction. because you are validating while
> the user is typing the serverside often gets the value that is out of
> date since the user types faster then you can send requests to the
> server. this means that when repainting the component on the
> serverside there is a good chance you will repaint it with the wrong
> value.
> 
> currently there is no way to tell a form component to repaint but not
> update its value attribute, and this is not always possible anyways.
> 
> -igor
> 
>>
>> Regards, Stefan
>>
>>
>> igor.vaynberg wrote:
>>>
>>> the way to do this is to have the div be output there without
>>> class="error" and to append the class to it via
>>> ajaxrequesttarget.appendjavascript("$(divid).addclass('error');");
>>>
>>> that way you do not need to repaint the input tag which is the
>>> problematic part for your usecase.
>>>
>>> -igor
>>>
>>> On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> My HTML looks similar to this:
>>>>
>>>> Foo
>>>>
>>>> I want to validate the contents of the field as soon as the user starts
>>>> typing. If there is an error, the html should become:
>>>>
>>>> There was an errorFoo>>> type="text"
>>>> />
>>>>
>>>> However, if I add the whole hierarchy to the AjaxRequestTarget, the
>>>> changes
>>>> in the text field get lost (Which results in quite weired typing
>>>> behavior).
>>>>
>>>> Is it possible to skip components from being updated within another
>>>> component? Might storing the value (prependJavascript), updating the
>>>> whole
>>>> hierarchy and writing back the stored value (appendJavascript) give
>>>> satisfying results.
>>>>
>>>> What do you think? Any other ideas?
>>>>
>>>> Thanks, Stefan
>>>>
>>>> -
>>>> ---
>>>> Stefan Fußenegger
>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.html
>> Sent from the

Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes


Thanks, I'll go for the suggested JS.Is there any documentation of the Wicket
JavaScript library available somewhere?

However, wouldn't be replacing borders (i.e. keeping parts of the hierarchy)
be a nice feature? I'd add a ticket if you agree.

Regards, Stefan


igor.vaynberg wrote:
> 
> the way to do this is to have the div be output there without
> class="error" and to append the class to it via
> ajaxrequesttarget.appendjavascript("$(divid).addclass('error');");
> 
> that way you do not need to repaint the input tag which is the
> problematic part for your usecase.
> 
> -igor
> 
> On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger
>  wrote:
>>
>> Hi,
>>
>> My HTML looks similar to this:
>>
>> Foo
>>
>> I want to validate the contents of the field as soon as the user starts
>> typing. If there is an error, the html should become:
>>
>> There was an errorFoo> />
>>
>> However, if I add the whole hierarchy to the AjaxRequestTarget, the
>> changes
>> in the text field get lost (Which results in quite weired typing
>> behavior).
>>
>> Is it possible to skip components from being updated within another
>> component? Might storing the value (prependJavascript), updating the
>> whole
>> hierarchy and writing back the stored value (appendJavascript) give
>> satisfying results.
>>
>> What do you think? Any other ideas?
>>
>> Thanks, Stefan
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Ajax-Update MarkupContaining containing FormComponent without loosing user changes

2009-01-13 Thread Stefan Fußenegger


Hi,

My HTML looks similar to this:

Foo

I want to validate the contents of the field as soon as the user starts
typing. If there is an error, the html should become:

There was an errorFoo

However, if I add the whole hierarchy to the AjaxRequestTarget, the changes
in the text field get lost (Which results in quite weired typing behavior).

Is it possible to skip components from being updated within another
component? Might storing the value (prependJavascript), updating the whole
hierarchy and writing back the stored value (appendJavascript) give
satisfying results.

What do you think? Any other ideas?

Thanks, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: code for DataGrid with vertical scrolling

2008-12-23 Thread Stefan Fußenegger

I once started working on a component that used vertical scrolling. It was
based on a GrowableListView (based on
http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/),

GrowableListView.java: http://pastie.org/345504 
GrowableListView.html: http://pastie.org/345507

Might not be the cleanest or best code ever, but it used to work - if I
remember correctly. This could be used to add columns to a single-row-table,
where each table cell contains a ListView of items

To use a table with the above code, call 

setItemTagName("td");
setContainerTagName("tr");

This table could than be scrolled with JS, e.g. with Dojo's
dojox.fx.smoothScroll(). That's the part I didn't finish so far, though :)
You'd probably be able to adapt the JS code found here:
http://www.songtexte.com/songtext/johnny-cash/folsom-prison-blues-3d41577.html
(see the "Videos" box in the right column) 

miro wrote:
> 
> please point me for the code with data grid vertical scrolling component.
> 
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/code-for-DataGrid-with-vertical-scrolling-tp21112343p21144910.html
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Dojo 1.1 integration available from wicketstuff

2008-12-23 Thread Stefan Fußenegger

Hi Emanuele,

I don't plan to support additional components myself - especially not
problems that seem to be caused by Dojo only. wicketstuff-dojo-1.1 is mainly
meant to ease the integration of Dojo into Wicket (i.e. to provide the
infrastructure like custom builds, packaging as jar files, configuration of
Dojo as part of a Wicket application, mounting resources and the like). In
the future, there might be more and more components available out of the
box. However, at the moment I don't have plans - or time - to add more
components than those already included (animations, toaster widget, drag and
drop and cometd support)

If you've built a Wicket component based on wicketstuff-dojo-1.1, you're
welcome to contribute your code. If you want to contribute but don't know
how, I'd be happy to get you started.

Merry Christmas, Stefan

Emanuele Gesuato-2 wrote:
> 
> Stefan Fußenegger wrote:
>> There's now a little bit of documentation online:
>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1
>> 
>> Cheers, Stefan
>> 
> 
> Hi,
> 
> First of all, good job.
> 
> Is there any plan to support the dojo context menu ?  :-)
> 
> We are using it but we've got several warnings with some deprecation 
> calls on the html document in development that are quite annoying.
> Also if i have different context menu in the same page and if these 
> context menu has submenus, the submenus are sharing the same instance of 
> the content component.
> 
> Example:
> If i have menuA and menuB in two tables, tableA and tableB. If i right 
> click on menuA or menuB in the java code i see that the referenced 
> component is always on tableB. This only happens in the voices of the 
> menu that are in a submenu.
> 
> 
> 
> Thanks for any help,
> Emanuele
> 
> 
> -----
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21144111.html
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Dojo 1.1 integration available from wicketstuff

2008-12-18 Thread Stefan Fußenegger


There's now a little bit of documentation online:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1

Cheers, Stefan


Stefan Fußenegger wrote:
> 
> Hi folks,
> 
> I just shared a new project called wicketstuff-dojo-1.1 [1], an
> integration of the Dojo JavaScript toolkit [2] into Wicket. This project
> is based on wicketstuff-dojo [3] and wicketstuff-push [4] (both based on
> dojo 0.4). However, not all of the components from wicketstuff-dojo have
> been ported to the new dojo version (but feel free to do so). 
> 
> Currently, there is no documentation available. I'll add some info to the
> wicketstuff wiki next week. In the meantime, (really) early adopters can
> check it out for review. To build the project, check it out and run `mvn
> clean install`. To build a custom dojo distribution, place your
> .profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/
> and run `mvn -Ddojo.profile= clean install`. In your project pom,
> add 
> 
> 
> org.wicketstuff
> wicketstuff-dojo-1.1
> 1.3.5-standard-SNAPSHOT
> 
> 
> or, for the custom profile
> 
> 
> org.wicketstuff
> wicketstuff-dojo-1.1
> 1.3.5--SNAPSHOT
> 
> 
> (Not sure if this versioning strategy is the best choice, but it makes it
> quite easy to use different custom profiles for different projects)
> 
> Looking forward to your feedback!
> 
> Regards, Stefan
> 
> [1]
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/
> [2] http://dojotoolkit.org/
> [3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo
> [4]
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21069750.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger


Hi Igor,

thanks for implementing this minimal version. i totally agree with your
reasoning. Is there any chance though that this goes into 1.3 branch as
well? I'd really appreciate that.

you mentioned that you implemented such a repeater yourself. didn't you use
any navigation or did you write that yourself? just wondering.

shall i open a ticket against 1.5 to track this issue/enhancement?

best regards, stefan



igor.vaynberg wrote:
> 
> On Thu, Nov 27, 2008 at 12:46 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> I don't think IDataProvider is only about databases.
> 
> you started off with your core assumption being wrong. idataprovider
> was written exclusively for accessing databases. my thinking, at the
> time, was that 99% of people use wicket to build applications that
> access databases, and i dare say it was a good guess because in its ~3
> years of existence only a handful of people had a problem with the way
> it works.
> 
>> There are other data
>> sources and some return the total amount and the desired subset at the
>> same
>> time (Lucene as a famous example). Such data sources would really benefit
>> of
>> a single-query-approach.
> 
> i am not disputing this fact. i am simply saying that we are not going
> to fix this right now because this is not a bug. you are trying to use
> the components for something they were not designed to be used. in 1.5
> we may address this.
> 
>> I faced this issue myself in a search (read Lucene)
>> centered application. I successfully went down the road of implementing a
>> custom repeater.
> 
> i had to do the same myself.
> 
>> But when the repeater was working as desired, I figured out
>> that PagingNavigationLink is the real showstopper, not IDataProvider (see
>> my
>> JIRA comment [0]). The fix would be rather trivial, as
>> PagingNavigationLink
>> is doing something it needn't do (checking the requested page against the
>> valid range of pages).
>>
>> Let me answer 2 possible questions in advance:
>>
>> Q: Why is this check in PagingNavigationLink a problem?
>> A: Obviously, you can't fetch size and data as long as the page isn't
>> known.
> 
> the check is there because we code defensively. we do not assume that
> every implementation of ipageable will cull the number when you call
> setcurrentpage(x).
> 
>> Q: How would a custom repeater that fetches data and size at the same
>> tame
>> handle invalid (out of range) pages?
>> A: Out of range pages will return the size and an empty dataset. In this
>> case, the repeater would change the page number to the last valid and do
>> a
>> second query. Yeah, two queries again. But this should only happen rarely
>> though.
> 
> this will change the existing behavior. if you are on page 5 and click
> page 10 (which happens to not exist) you would end up back on 5 with
> your suggestion where as currently you would properly end up on 9.
> 
> looking at WICKET-1784, i extracted the code you want into an
> overridable int cullPageNumber(int x). so feel free to subclass the
> link and override that to return x without any extra checks.
> 
> we may properly fix this in 1.5, but for right now this is too big a
> refactor because it changes the basic assumptions with which the code
> was written.
> 
> -igor
> 
>>
>> Best regards, Stefan
>>
>> [0]
>> https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278
>>
>>
>> igor.vaynberg wrote:
>>>
>>> On Wed, Nov 26, 2008 at 9:32 AM, Wayne Pope
>>> <[EMAIL PROTECTED]> wrote:
>>>>>so you think pushing all that extra data over the network is actually
>>>>>more efficient then doing another query wtf.
>>>> The point is I'd rather avoid 2 calls where 1 will do.
>>>> AbstractPageableView
>>>> will do fine I believe.
>>>
>>> the number of calls itself is meaningless, i dont comprehend why
>>> people have a hard time understanding this simple fact.
>>>
>>> if you have one call that takes 1000ms and ten calls that each take
>>> 10ms you should concentrate on the one call that takes a long time
>>> rather then eliminating all ten 10ms calls which only saves you 100ms.
>>> if you can optimize the 1000ms and shave off 20% then your eleven
>>> calls are still faster then the one call.
>>>
>>> and since connection pools have been inventind many years ago there is
>>> no more overhead of establishing network connections, just push

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger

ing a significant chunk of
>>> processing time in the database server? to the point where eliminating
>>> it will actually reduce enough load on the database to increase your
>>> throughput?
>>>
>>> -igor
>>>
>>> >
>>> > Wayne
>>> >
>>> >
>>> > On Wed, Nov 26, 2008 at 5:58 PM, Igor Vaynberg
>>> <[EMAIL PROTECTED]
>>> >wrote:
>>> >
>>> >> On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
>>> >> <[EMAIL PROTECTED]> wrote:
>>> >> > I'm sure I must be missing something still, as I can't beleive that
>>> we
>>> >> need
>>> >> > to either a) load the whole data set
>>> >>
>>> >> what? why would you ever load the whole dataset?
>>> >>
>>> >> b) call count on the Db , then load in
>>> >> > the iterator mehod. Thats going to kill the database in prod (or
>>> really
>>> >> not
>>> >> > help.)
>>> >>
>>> >> yeah. because select count() queries are the most expensive queries
>>> >> you can run on the database. you are right, its totally going to kill
>>> >> it. you know how all those sites on the internet that have a pager
>>> >> above the pageable view that shows you the number of the last
>>> >> available page...you know how those work without doing a select
>>> >> count()?
>>> >>
>>> >> -igor
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> >
>>> >> > On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer <
>>> [EMAIL PROTECTED]
>>> >> >wrote:
>>> >> >
>>> >> >>
>>> >> >> have a look at https://issues.apache.org/jira/browse/WICKET-1784
>>> >> >>
>>> >> >>
>>> >> >> Wayne Pope-2 wrote:
>>> >> >> >
>>> >> >> > Ok,
>>> >> >> >
>>> >> >> > I was just having a bit of code clean up and I realized that in
>>> our
>>> >> >> > IDataProviders we are loading all rows for a given dataset.
>>> >> >> > So looking at the iterator method I see we can limit the result
>>> (and
>>> >> the
>>> >> >> > offset). Great I thought - however I see that that the size()
>>> method
>>> >> is
>>> >> >> > called as part of the getViewSize() in the AbstractPageableView.
>>> Thus
>>> >> I
>>> >> >> > need
>>> >> >> > to call the database here to figure out the size.
>>> >> >> >
>>> >> >> > Am I doing sonething wrong or have I got to hit the database
>>> twice
>>> for
>>> >> >> > each
>>> >> >> > DataProvider render.
>>> >> >> >
>>> >> >> > Obvously I don't want to hard code a size. Is there any other
>>> way ?
>>> >> >> >
>>> >> >> > Thanks
>>> >> >> > Wayne
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> -
>>> >> >> Michael Sparer
>>> >> >> http://talk-on-tech.blogspot.com
>>> >> >> --
>>> >> >> View this message in context:
>>> >> >>
>>> >>
>>> http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.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]
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >> -
>>> >> 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]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20715382.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: wicketstuff-push is over, wickestuff-dojo-1.1 is born ???

2008-11-21 Thread Stefan Fußenegger


see
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-to20625220.html


Michael Sparer wrote:
> 
> Hi Julien, 
> 
> we're doing our last tests today and tomorrow and will put
> wicketstuff-dojo-1.1 into production by Monday. If no issues arise, we'll
> share it as a wicketstuff project next week. Please note that so far, we
> only ported some components to 1.1. (includes wiper, slider, drag and drop
> and cometd). We're also making extensive use of cometd, which is quite a
> bit better than in dojo 0.4 by the way, and it is also included in the
> wicketstuff-dojo-1.1 project then. Then it's your turn to give
> recommendations, improvements and, most important, help to get the same
> functionality working for 1.1.
> 
> as for the corrupted push project: rodolfo made some changes, so I don't
> know what's going on there. A version of wicketstuff-push before rodolfo
> started with the makeover is available as a branch. Just check out
> wicketstuff's branches, if you can't wait till next week.
> 
> regards,
> Michael
> 
> 
> julien Graglia wrote:
>> 
>> Hi,
>> I have read some posts (1) that seems to say that wicketstuff-push will
>> be replaced by a new wicketstuff-dojo-1.1 artifact.
>> 
>> The post says that this artifact is in a private SVN repo, but will be
>> available "shortly"..
>> 
>> Do you have any informations about that?
>> 
>> I need to do reverse ajax with wicket (cometd...) ie. push event from a
>> server thread at the server initiative. It works with an old (rev 4245)
>> version  of wicketstuff-push. The trunk seems "corrupted" : a "dojo"
>> folder is missing..
>> 
>> 
>> 
>> 1 : http://www.nabble.com/New-wicketstuff-dojo-project-td19070145.html
>> -- 
>> Julien Graglia
>> NetCeler
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/wicketstuff-push-is-over%2C-wickestuff-dojo-1.1-is-born-tp20356751p20625246.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]

Dojo 1.1 integration available from wicketstuff

2008-11-21 Thread Stefan Fußenegger


Hi folks,

I just shared a new project called wicketstuff-dojo-1.1 [1], an integration
of the Dojo JavaScript toolkit [2] into Wicket. This project is based on
wicketstuff-dojo [3] and wicketstuff-push [4] (both based on dojo 0.4).
However, not all of the components from wicketstuff-dojo have been ported to
the new dojo version (but feel free to do so). 

Currently, there is no documentation available. I'll add some info to the
wicketstuff wiki next week. In the meantime, (really) early adopters can
check it out for review. To build the project, check it out and run `mvn
clean install`. To build a custom dojo distribution, place your
.profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/
and run `mvn -Ddojo.profile= clean install`. In your project pom,
add 


org.wicketstuff
wicketstuff-dojo-1.1
1.3.5-standard-SNAPSHOT


or, for the custom profile


org.wicketstuff
wicketstuff-dojo-1.1
1.3.5--SNAPSHOT


(Not sure if this versioning strategy is the best choice, but it makes it
quite easy to use different custom profiles for different projects)

Looking forward to your feedback!

Regards, Stefan

[1]
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/
[2] http://dojotoolkit.org/
[3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo
[4]
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p20625220.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: AjaxFallbackButton: inconsistend submit order

2008-10-24 Thread Stefan Fußenegger


https://issues.apache.org/jira/browse/WICKET-1894

btw: 1.3.5 is still in the "unreleased versions" section

regards



igor.vaynberg wrote:
> 
> this sounds like a bug, please file a jira report
> 
> -igor
> 
> On Thu, Oct 23, 2008 at 6:47 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi folks,
>>
>> I just stumbled upon a problem with a Form containing a nested Form and
>> two
>> AjaxFallbackButtons (submit and preview). I need to implement different
>> onSubmit() behavior of the nested Form depending on the clicked button.
>>
>> The order of onSubmit() calls is:
>>
>> without JS:
>> - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)
>> - OuterForm.onSubmit() // not used
>> - Inner Form.onSubmit()
>>
>> with JS:
>> - Inner Form.onSubmit()
>> - OuterForm.onSubmit() // not used
>> - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)
>>
>> With JS, it is therefore not possible to determine which button was
>> clicked
>> from inside a form's onSubmit() method.
>>
>> Is this a (known) bug?
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20131329.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]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20145832.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]

AjaxFallbackButton: inconsistend submit order

2008-10-23 Thread Stefan Fußenegger


Hi folks,

I just stumbled upon a problem with a Form containing a nested Form and two
AjaxFallbackButtons (submit and preview). I need to implement different
onSubmit() behavior of the nested Form depending on the clicked button.

The order of onSubmit() calls is:

without JS:
- AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)
- OuterForm.onSubmit() // not used
- Inner Form.onSubmit()

with JS:
- Inner Form.onSubmit()
- OuterForm.onSubmit() // not used
- AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form)

With JS, it is therefore not possible to determine which button was clicked
from inside a form's onSubmit() method.

Is this a (known) bug?

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20131329.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: Discussion on "Wicket Interface Speed-Up"

2008-09-01 Thread Stefan Fußenegger


wicketstuff-merged-resources is now available in JIRA:

http://wicketstuff.org/jira/browse/WMR

and from wicketstuff maven repo:


wicket-snaps
http://wicketstuff.org/maven/repository

true


true





  org.wicketstuff
  wicketstuff-merged-resources
  1.3.4-SNAPSHOT


i am also going to add a short wiki page at wicketstuff.org

regards, Stefan



Jörn Zaefferer-2 wrote:
> 
> Good point, I forgot that wicketstuff has its own JIRA installation.
> Though the entry for the project is missing. Let me know once its
> there, and I'll create the report.
> 
> Jörn
> 
> On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote:
>> why don't you open up an issue in JIRA?
>>
>>
>> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
>>
>>> Here is a first patch for the RevisionVersionProvider:
>>>
>>> Index:
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>> ===
>>> ---
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>>(revision
>>> 4147)
>>> +++
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>>(working
>>> copy)
>>> @@ -15,7 +15,7 @@
>>>
>>>public int getVersion(final Class scope, final String
>>> fileName)
>>> throws VersionException {
>>>final String file = getResourcePath(scope, fileName);
>>> -   final InputStream in =
>>> ClassLoader.getSystemResourceAsStream(file);
>>> +   final InputStream in =
>>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
>>>if (in == null) {
>>>throw new VersionException(scope, fileName,
>>> "can't
>>> find " + file);
>>>}
>>>
>>>
>>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
>>> always returned null for classpath resources. Using the
>>> RevisionVersionProvider classloader works fine.
>>>
>>> Let me know where I should post further patches etc.
>>>
>>> Jörn
>>>
>>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Code is now available through wicketsuff:
>>>>
>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>>>> wicketstuff-merged-resources  and
>>>>
>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>>>> wicketstuff-merged-resources-examples
>>>>
>>>> Now I want to make it available through
>>>> http://wicketstuff.org/maven/repository/. I therefore registered at
>>>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>>>
>>>>
>>>> Stefan Fußenegger wrote:
>>>>>
>>>>> I just finished the 4th and last entry of my series "Wicket Interface
>>>>> Speed-Up" on my blog. To give a short summary: I investigated one of
>>>>> my
>>>>> apps with YSlow and started optimizing it's interface rendering speed
>>>>> [1].
>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>>>> causes interfaces to load rather slowly. In my articles, I explain how
>>>>> to
>>>>> modify the cache interval [2], how to mount resources with a version
>>>>> (e.g.
>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>> (e.g.
>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>> resources
>>>>> at application startup (using a class classed MergedResourceStream) to
>>>>> reduce the number of resources a client has to download [4], including
>>>>> code). I was able to increase interface loading times considerably, so
>>>>> it's surely worth a look.
>>>>>
>>>>> I feel that it would also be worth to discuss, whether this work could
>>>>> be
>>>>> part of upcoming Wicket versions. For the tim

Re: Discussion on "Wicket Interface Speed-Up"


just applied your patch

could somebody please create wicketstuff-merged-resources in JIRA and
teamcity?


Jörn Zaefferer-2 wrote:
> 
> Here is a first patch for the RevisionVersionProvider:
> 
> Index:
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> ===
> ---
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> (revision
> 4147)
> +++
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> (working
> copy)
> @@ -15,7 +15,7 @@
>   
>   public int getVersion(final Class scope, final String fileName)
> throws VersionException {
>   final String file = getResourcePath(scope, fileName);
> - final InputStream in = 
> ClassLoader.getSystemResourceAsStream(file);
> + final InputStream in =
> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
>   if (in == null) {
>   throw new VersionException(scope, fileName, "can't find 
> " + file);
>   }
> 
> 
> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
> always returned null for classpath resources. Using the
> RevisionVersionProvider classloader works fine.
> 
> Let me know where I should post further patches etc.
> 
> Jörn
> 
> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> Code is now available through wicketsuff:
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>> wicketstuff-merged-resources  and
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>> wicketstuff-merged-resources-examples
>>
>> Now I want to make it available through
>> http://wicketstuff.org/maven/repository/. I therefore registered at
>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>
>>
>> Stefan Fußenegger wrote:
>>>
>>> I just finished the 4th and last entry of my series "Wicket Interface
>>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>>> apps with YSlow and started optimizing it's interface rendering speed
>>> [1].
>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>> causes interfaces to load rather slowly. In my articles, I explain how
>>> to
>>> modify the cache interval [2], how to mount resources with a version
>>> (e.g.
>>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>>> resources expire after a year) [3]. Finally, I show how to merge
>>> resources
>>> at application startup (using a class classed MergedResourceStream) to
>>> reduce the number of resources a client has to download [4], including
>>> code). I was able to increase interface loading times considerably, so
>>> it's surely worth a look.
>>>
>>> I feel that it would also be worth to discuss, whether this work could
>>> be
>>> part of upcoming Wicket versions. For the time being I'd like to make
>>> the
>>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>>> access ;) - and wait for your feedback.
>>>
>>> The links:
>>> [1]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>> Wicket Interface Speed-Up
>>> [2]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>>> [3]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>> Wicket Interface Speed-Up: Caching Resources Forever
>>> [4]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>
>>
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.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]
>>
>>
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19218353.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: Discussion on "Wicket Interface Speed-Up"


Code is now available through wicketsuff: 
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources  and 
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples 

Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?


Stefan Fußenegger wrote:
> 
> I just finished the 4th and last entry of my series "Wicket Interface
> Speed-Up" on my blog. To give a short summary: I investigated one of my
> apps with YSlow and started optimizing it's interface rendering speed [1].
> Especially Wicket's way of handling resources, i.e. JS and CSS files,
> causes interfaces to load rather slowly. In my articles, I explain how to
> modify the cache interval [2], how to mount resources with a version (e.g.
> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
> resources expire after a year) [3]. Finally, I show how to merge resources
> at application startup (using a class classed MergedResourceStream) to
> reduce the number of resources a client has to download [4], including
> code). I was able to increase interface loading times considerably, so
> it's surely worth a look. 
> 
> I feel that it would also be worth to discuss, whether this work could be
> part of upcoming Wicket versions. For the time being I'd like to make the
> code attached to [4] a wicketstuff project - sfussenegger needs commit
> access ;) - and wait for your feedback.
> 
> The links:
> [1] 
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
> Wicket Interface Speed-Up 
> [2] 
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers 
> [3] 
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
> Wicket Interface Speed-Up: Caching Resources Forever 
> [4] 
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.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: Discussion on "Wicket Interface Speed-Up"


Sounds promising ... and little mysterious ;) Any concrete plans/ideas so
far?


Matej Knopp-2 wrote:
> 
> On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <[EMAIL PROTECTED]> wrote:
>> I totally agree that having the version in the filename and not in the
>> query
>> string will be a-lot-better.
>>
>> Just wanted to point you to that option so you can include it in your
>> excellent analysis on caching *thanks* :-)
>>
>> People can use that option right now and get a more decent version later
>> (e.g. your versioned resource filenames, which is the *correct* way)
>>
>> Resources need some more love in wicket 1.5 - full ack!
>>
> And they are going to get it :) Resources are going to be much simpler
> in 1.5 - current code is too tangled and ambiguous.
> 
> -Matej
>> Cheers
>> Peter
>>
>>
>> Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger:
>>
>>>
>>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
>>> option.
>>> However, changing filename instead of using query string has certain
>>> advantages, see
>>>
>>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>>>
>>> Furthermore, setting this option does not effect expires or
>>> cache-control
>>> headers. still only one hour, which is far from being aggressive. If you
>>> want to change that, you'll still have to explicitly mount all resources
>>> with your desired cache duration.
>>>
>>> Johan suggested (comment on
>>>
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> my second article ) "what i can do is make it a setting:
>>> IResourceSettings.getResourceCacheDuration()". If such a setting is
>>> available, using
>>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true)
>>> would
>>> make more sense.
>>>
>>> I still think though that this isn't enough and resources should get a
>>> focus
>>> in upcoming wicket versions. Some might argue, that resources shouldn't
>>> be
>>> served by Wicket at all, but I really don't like to use proxies, CDNs or
>>> whatever voodoo for low traffic web sites: server-side performance isn't
>>> an
>>> issue there while client-side performance is.
>>>
>>> regards
>>>
>>>
>>> Peter Ertl wrote:
>>>>
>>>> That's not true.
>>>>
>>>> this settings will generate urls like:
>>>>
>>>>  /resources/[package+class]/javascript.js?lm=[lastmodified]
>>>>
>>>> read it again : "add Last Modified Time To Resource Reference Url"
>>>>
>>>>>> getApplication
>>>>>> ().getResourceSettings
>>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
>>>>
>>>> It will not sent the "LastModified" header as you think.
>>>>
>>>> So whenever the resource changes the url changes, too.
>>>>
>>>> Try it out and see :-)
>>>>
>>>> I did test it in Firefox. There will be no "IfModified" requests from
>>>> the browser.
>>>>
>>>> Everything will be completely cached in the browser until the resource
>>>> has changed.
>>>>
>>>> Cheers
>>>> Peter
>>>>
>>>>
>>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>>>
>>>>>
>>>>> honestly, no, I didn't. however, using last modified times still
>>>>> results in
>>>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>>>> but
>>>>> client-side caching is still preferable.
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>> Peter Ertl wrote:
>>>>>>
>>>>>> @stefan: did you take into account
>>>>>>
>>>>>>
>>>>>> getApplication
>>>>>> ().getResourceSettings
>>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
>>>>>>
>>>>>> Cheers
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>>>
>>>>>>&g

Re: Discussion on "Wicket Interface Speed-Up"


I would love to see an approach where Wicket itself tries to determine a
version. If a version is available, wicket would than add it to the filename
and use an aggressive caching duration, e.g. 1 year. (no version, no
caching)

Additionally, what I currently don't like is that resource creation isn't
flexible at all. The current approach (ResourceReference.newResource()
called in ResourceReference.bind(Application) if resource isn't already
bound) doesn't allow to change default resources, as one can't change the
used ResourceReference type.

I'd suggest - just thinking aloud right now - to change the current
implementation to either
Application.get().getResourceFactory().newResource(ResourceReference)
instead of ResourceReference.newResource() or to make the ResourceReference
type used within HeaderContributor.for...(..) changeable:

response.renderJavascriptReference(new JavascriptResourceReference(scope,
path)); // current
response.renderJavascriptReference(Application.get().getResourceFactory().newJavascriptResourceReference(scope,
path));

both approaches would allow to customize resource creation.

regards



Johan Compagner wrote:
> 
> I thing we should look at what that append to url does, because i dont
> like the query string either, i also rather have it in the url path
> itself.
> 
> Also such a resource cache duration can be added. But i also rather
> have it configured by resoure(reference) like
> 
> HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod)
> 
> Johan
> 
> On 8/29/08, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>>
>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
>> option.
>> However, changing filename instead of using query string has certain
>> advantages, see
>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>>
>> Furthermore, setting this option does not effect expires or cache-control
>> headers. still only one hour, which is far from being aggressive. If you
>> want to change that, you'll still have to explicitly mount all resources
>> with your desired cache duration.
>>
>> Johan suggested (comment on
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> my second article ) "what i can do is make it a setting:
>> IResourceSettings.getResourceCacheDuration()". If such a setting is
>> available, using
>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true)
>> would
>> make more sense.
>>
>> I still think though that this isn't enough and resources should get a
>> focus
>> in upcoming wicket versions. Some might argue, that resources shouldn't
>> be
>> served by Wicket at all, but I really don't like to use proxies, CDNs or
>> whatever voodoo for low traffic web sites: server-side performance isn't
>> an
>> issue there while client-side performance is.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> That's not true.
>>>
>>> this settings will generate urls like:
>>>
>>>/resources/[package+class]/javascript.js?lm=[lastmodified]
>>>
>>> read it again : "add Last Modified Time To Resource Reference Url"
>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
>>>
>>> It will not sent the "LastModified" header as you think.
>>>
>>> So whenever the resource changes the url changes, too.
>>>
>>> Try it out and see :-)
>>>
>>> I did test it in Firefox. There will be no "IfModified" requests from
>>> the browser.
>>>
>>> Everything will be completely cached in the browser until the resource
>>> has changed.
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>>
>>>>
>>>> honestly, no, I didn't. however, using last modified times still
>>>> results in
>>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>>> but
>>>> client-side caching is still preferable.
>>>>
>>>> regards
>>>>
>>>>
>>>> Peter Ertl wrote:
>>>>>
>>>>> @stefan: did you take into account
>>>>>
>>>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastMo

Re: Discussion on "Wicket Interface Speed-Up"


Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option.
However, changing filename instead of using query string has certain
advantages, see
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Furthermore, setting this option does not effect expires or cache-control
headers. still only one hour, which is far from being aggressive. If you
want to change that, you'll still have to explicitly mount all resources
with your desired cache duration.

Johan suggested (comment on 
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
my second article ) "what i can do is make it a setting:
IResourceSettings.getResourceCacheDuration()". If such a setting is
available, using
IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would
make more sense. 

I still think though that this isn't enough and resources should get a focus
in upcoming wicket versions. Some might argue, that resources shouldn't be
served by Wicket at all, but I really don't like to use proxies, CDNs or
whatever voodoo for low traffic web sites: server-side performance isn't an
issue there while client-side performance is.

regards


Peter Ertl wrote:
> 
> That's not true.
> 
> this settings will generate urls like:
> 
>/resources/[package+class]/javascript.js?lm=[lastmodified]
> 
> read it again : "add Last Modified Time To Resource Reference Url"
> 
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
> 
> It will not sent the "LastModified" header as you think.
> 
> So whenever the resource changes the url changes, too.
> 
> Try it out and see :-)
> 
> I did test it in Firefox. There will be no "IfModified" requests from  
> the browser.
> 
> Everything will be completely cached in the browser until the resource  
> has changed.
> 
> Cheers
> Peter
> 
> 
> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
> 
>>
>> honestly, no, I didn't. however, using last modified times still  
>> results in
>> an HTTP request and a "304 Not Modified" reply. better than nothing,  
>> but
>> client-side caching is still preferable.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> @stefan: did you take into account
>>>
>>>
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>
>>>> sfussenegger now has access to wicketstuff...
>>>>
>>>> i dont know which parts should go into wicket itself, i can tell you
>>>> that the part where you merge the files by listing them out  
>>>> upfront is
>>>> probably not going to make it in because it breaks encapsulation...
>>>>
>>>> -igor
>>>>
>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> I just finished the 4th and last entry of my series "Wicket  
>>>>> Interface
>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>> of my apps
>>>>> with YSlow and started optimizing it's interface rendering speed  
>>>>> [1].
>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>> files, causes
>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>> modify
>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>> (e.g.
>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>> resources
>>>>> at application startup (using a class classed MergedResourceStream)
>>>>> to
>>>>> reduce the number of resources a client has to download [4],
>>>>> including
>>>>> code). I was able to increase interface loading times considerably,
>>>>> so it's
>>>>> surely worth a look.
>>>>>
>>>>> I feel that it would also be worth to discuss, whether this work
>>>>> could be
>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>> make the
>>>>

Re: Discussion on "Wicket Interface Speed-Up"

2008-08-28 Thread Stefan Fußenegger


you're right with the encapsulation, but i feel that resource versioning (and
aggressive client side caching) could be a nice addition to wicket. but
maybe sombody can think of another way to reduce (merge) resources without
breaking encapsulation ...

btw, resource versioning also works with wicket-ajax.js and wicket-event.js:

protected void init() {
  final String version = getFrameworkSettings().getVersion();
  final String suffix = ("n/a".equals(version) ? "" : "-" + version) +
".js";

  getSharedResources().add(WicketAjaxReference.INSTANCE.getName(),
getResourceReference(WicketAjaxReference.class,
"wicket-ajax.js").getResource());
  mountSharedResourceWithCaching("/scripts/wicket-ajax" + suffix,
WicketAjaxReference.INSTANCE.getSharedResourceKey());

  getSharedResources().add(WicketEventReference.INSTANCE.getName(),
getResourceReference(WicketEventReference.class,
"wicket-event.js").getResource());
  mountSharedResourceWithCaching("/scripts/wicket-event" + suffix,
WicketEventReference.INSTANCE.getSharedResourceKey());
}

// it's getting dirty ...
protected void mountSharedResourceWithCaching(final String path, final
String resourceKey) {
  mount(new SharedResourceRequestTargetUrlCodingStrategy(path, resourceKey)
{
public IRequestTarget decode(final RequestParameters requestParameters)
{
  final SharedResourceRequestTarget t = (SharedResourceRequestTarget)
super.decode(requestParameters);
  if (t != null) {
  // wrap target
return new IRequestTarget() {
  public void detach(final RequestCycle requestCycle)
{t.detach(requestCycle);}

  public void respond(final RequestCycle requestCycle) {
t.respond(requestCycle);
final WebResponse response = (WebResponse)
requestCycle.getResponse();
response.setDateHeader("Expires", System.currentTimeMillis() +
CACHE_DURATION * 1000L);
response.setHeader("Cache-Control", "max-age=" +
CACHE_DURATION);
  }
};
  } else {
return null;
  }
}
  });
}

regards


igor.vaynberg wrote:
> 
> sfussenegger now has access to wicketstuff...
> 
> i dont know which parts should go into wicket itself, i can tell you
> that the part where you merge the files by listing them out upfront is
> probably not going to make it in because it breaks encapsulation...
> 
> -igor
> 
> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> I just finished the 4th and last entry of my series "Wicket Interface
>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>> apps
>> with YSlow and started optimizing it's interface rendering speed [1].
>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>> causes
>> interfaces to load rather slowly. In my articles, I explain how to modify
>> the cache interval [2], how to mount resources with a version (e.g.
>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>> resources expire after a year) [3]. Finally, I show how to merge
>> resources
>> at application startup (using a class classed MergedResourceStream) to
>> reduce the number of resources a client has to download [4], including
>> code). I was able to increase interface loading times considerably, so
>> it's
>> surely worth a look.
>>
>> I feel that it would also be worth to discuss, whether this work could be
>> part of upcoming Wicket versions. For the time being I'd like to make the
>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>> access ;) - and wait for your feedback.
>>
>> The links:
>> [1] 
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>> Wicket Interface Speed-Up
>> [2]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>> [3]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>> Wicket Interface Speed-Up: Caching Resources Forever
>> [4]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---

Re: Discussion on "Wicket Interface Speed-Up"

2008-08-28 Thread Stefan Fußenegger


honestly, no, I didn't. however, using last modified times still results in
an HTTP request and a "304 Not Modified" reply. better than nothing, but
client-side caching is still preferable.

regards


Peter Ertl wrote:
> 
> @stefan: did you take into account
> 
>  
> getApplication 
> ().getResourceSettings 
> ().setAddLastModifiedTimeToResourceReferenceUrl(true)??
> 
> Cheers
> Peter
> 
> 
> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
> 
>> sfussenegger now has access to wicketstuff...
>>
>> i dont know which parts should go into wicket itself, i can tell you
>> that the part where you merge the files by listing them out upfront is
>> probably not going to make it in because it breaks encapsulation...
>>
>> -igor
>>
>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> I just finished the 4th and last entry of my series "Wicket Interface
>>> Speed-Up" on my blog. To give a short summary: I investigated one  
>>> of my apps
>>> with YSlow and started optimizing it's interface rendering speed [1].
>>> Especially Wicket's way of handling resources, i.e. JS and CSS  
>>> files, causes
>>> interfaces to load rather slowly. In my articles, I explain how to  
>>> modify
>>> the cache interval [2], how to mount resources with a version (e.g.
>>> /css/all-1234.css) in order to use aggressive client-side caching  
>>> (e.g.
>>> resources expire after a year) [3]. Finally, I show how to merge  
>>> resources
>>> at application startup (using a class classed MergedResourceStream)  
>>> to
>>> reduce the number of resources a client has to download [4],  
>>> including
>>> code). I was able to increase interface loading times considerably,  
>>> so it's
>>> surely worth a look.
>>>
>>> I feel that it would also be worth to discuss, whether this work  
>>> could be
>>> part of upcoming Wicket versions. For the time being I'd like to  
>>> make the
>>> code attached to [4] a wicketstuff project - sfussenegger needs  
>>> commit
>>> access ;) - and wait for your feedback.
>>>
>>> The links:
>>> [1] 
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>> Wicket Interface Speed-Up
>>> [2]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control  
>>> Headers
>>> [3]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>> Wicket Interface Speed-Up: Caching Resources Forever
>>> [4]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>
>>> -
>>> ---
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.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]
>>>
>>>
>>
>> -
>> 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]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.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]

Discussion on "Wicket Interface Speed-Up"

2008-08-28 Thread Stefan Fußenegger


I just finished the 4th and last entry of my series "Wicket Interface
Speed-Up" on my blog. To give a short summary: I investigated one of my apps
with YSlow and started optimizing it's interface rendering speed [1].
Especially Wicket's way of handling resources, i.e. JS and CSS files, causes
interfaces to load rather slowly. In my articles, I explain how to modify
the cache interval [2], how to mount resources with a version (e.g.
/css/all-1234.css) in order to use aggressive client-side caching (e.g.
resources expire after a year) [3]. Finally, I show how to merge resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so it's
surely worth a look. 

I feel that it would also be worth to discuss, whether this work could be
part of upcoming Wicket versions. For the time being I'd like to make the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.

The links:
[1]  http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up 
[2] 
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers 
[3] 
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever 
[4] 
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.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: Escaping of strings containing & in attributes

2008-08-05 Thread Stefan Fußenegger


no comments here?


Stefan Fußenegger wrote:
> 
> While validating some of my pages, I found out that some pages do not
> validate due to & in attributes, e.g. 
> 
>  
> 
> W3 validator complains with: "character "&" is the first character of a
> delimiter but occurred as data."
> 
> I'm doing the following in code:
> 
> class Image { String path; String alt; }
> 
> // for StaticImage see
> http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html
> final StaticImage img = new StaticImage("image", new PropertyModel(img,
> "path")));
> img.add(new AttributeModifier("alt", true, new PropertyModel(img,
> "alt")));
> 
> if alt contains "foo & bar", the page won't validate. I think using
> PropertyModel together with AttributeModifier is quite common. however,
> the beans won't contain escaped markup ... hopefully ;)
> 
> Should this be considered a bug? For the time beeing I use:
> 
> new AttributeModifier("alt", true, new Model(album.getName())) {
>   protected String newValue(final String currentValue, final String
> replacementValue) {
> return Strings.escapeMarkup(replacementValue).toString();
>   }
> }
> 
> 
> 
> btw: While looking for answers, I also found this (quite old) thread:
> 
> http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344
> 
> Al Maw mentions a comment in code: "attributes without values are
> possible, e.g. 'disabled'" inside ComponentTag.writeOutput(...). As
> mentioned and suggested in this thread, this is not true for XHTML and
> should probably be fixed. However, the comment (and corresponding code) is
> still there (at least in wicket 1.3.4).
> 
> best regards and nice weekend!
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18832765.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]

Escaping of strings containing & in attributes

2008-08-01 Thread Stefan Fußenegger


While validating some of my pages, I found out that some pages do not
validate due to & in attributes, e.g. 



W3 validator complains with: "character "&" is the first character of a
delimiter but occurred as data."

I'm doing the following in code:

class Image { String path; String alt; }

// for StaticImage see
http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html
final StaticImage img = new StaticImage("image", new PropertyModel(img,
"path")));
img.add(new AttributeModifier("alt", true, new PropertyModel(img, "alt")));

if alt contains "foo & bar", the page won't validate. I think using
PropertyModel together with AttributeModifier is quite common. however, the
beans won't contain escaped markup ... hopefully ;)

Should this be considered a bug? For the time beeing I use:

new AttributeModifier("alt", true, new Model(album.getName())) {
  protected String newValue(final String currentValue, final String
replacementValue) {
return Strings.escapeMarkup(replacementValue).toString();
  }
}



btw: While looking for answers, I also found this (quite old) thread:

http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344

Al Maw mentions a comment in code: "attributes without values are possible,
e.g. 'disabled'" inside ComponentTag.writeOutput(...). As mentioned and
suggested in this thread, this is not true for XHTML and should probably be
fixed. However, the comment (and corresponding code) is still there (at
least in wicket 1.3.4).

best regards and nice weekend!

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18779532.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: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-19 Thread Stefan Fußenegger


Hi,

According to https://issues.apache.org/jira/browse/WICKET-1667 this issue
will be fixed in Wicket 1.3.4 and 1.4-M3 respectively. I already put the
patch into production and it works. Thanks to Igor!

Regards, Stefan


Heart wrote:
> 
> I've met the same problem several days away and resovled it by override a
> method of Localizer
> 
> see:
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--to17142582.html#a17182935
> 
> that may help you a little.
> 
> 
> 2008/6/9 Stefan Fußenegger <[EMAIL PROTECTED]>:
> 
>>
>> I am just analysing a heap dump (god bless the
>> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due
>> to
>> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using
>> jhat, the "175456 instances of class
>> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately
>> got
>> my attention. While looking through the 107 instance of
>> ConcurrentHashMap,
>> I
>> found one *really* big one: Localizer.cache has a hash table length of
>> 262144, each of its 32 segments with about 5300 entries, where a hash key
>> is
>> a string, sometimes longer than 500 charactes, similar to (see
>> Localizer.getCacheKey(String,Component)):
>>
>>
>> fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null
>>
>> Those numbers pretty much convinced me: The localizer cache has blown
>> away
>> my application.
>>
>> Looking at this hash keys, I suspect the following problem: those strings
>> are constructed from the "position" of a localized String on a page,
>> which
>> is quite a bad thing if you use nested list views or repeating views to
>> construct your page. For instance, I have a panel with a long (pageable)
>> list of entries, might be > 5000 entries which might appear on various
>> positions in a repeating view I use as a container for most of my pages.
>> Let's say there are 5 possible positions, this would cause 2500 thousand
>> cached entries, each with a key of 300+ characters plus some more
>> characters
>> for the cached message - feel free to do the maths. From a quick estimate
>> I'd say: No wonder, this has blown away my app.
>>
>> As a quick fix, I'd suggest to regularly clear the localizer cache, use a
>> more sophisticated cache (that expires old entries once in a while!!) or
>> to
>> disable the cache completely. However, don't try to overwrite
>> Localizer.newCache() and clear the cache regularly: clearCache() will
>> replace your cache with a ConcurrentHashMap (not using
>> Localizer.newCache()). However, quite unlikely, that this will happen as
>> newCache() is private anyway ;) I am going to add some code to clear the
>> cache regularly.
>>
>> Best regards, Stefan
>>
>> PS: I'll also create a JIRA issue, but I am really short on time right
>> now.
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]
>>
>>
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p18000380.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: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-10 Thread Stefan Fußenegger


Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm), as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:
> 
> So the patch did help?
> 
> I too have observed this problem but it was at the moment less of a  
> problem than other heap eaters, now this is next in line. We have  
> added a script which automatically restarts the server when repeated  
> OOME occurs and are down to a couple of times per week without the  
> patch. But still, who wouldn't want to see months of uptime...
> 
> // Daniel
> jalbum.net
> 
> 
> On 2008-06-10, at 11:29, Stefan Fußenegger wrote:
> 
>>
>> Hi Igor,
>>
>> Thanks for your quick reply and the patch, sorry for not searching the
>> mailinglist only but not JIRA.
>>
>> Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
>> including JUnit test and attached it to the JIRA issue. Hope this  
>> fix gets
>> into the next maintenance release. I am to lazy to create a properly  
>> patched
>> jar and a MVN repo for my team right now ;)
>>
>> Regards, Stefan
>>
>>
>>
>> igor.vaynberg wrote:
>>>
>>> try applying this patch and see if it helps
>>>
>>> https://issues.apache.org/jira/browse/WICKET-1667
>>>
>>> -igor
>>>
>>> On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>> I am just analysing a heap dump (god bless the
>>>> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  
>>>> cache due
>>>> to
>>>> an OutOfMemoryError ("GC overhead limit exceeded" to be precise).  
>>>> Using
>>>> jhat, the "175456 instances of class
>>>> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry"  
>>>> immediately
>>>> got
>>>> my attention. While looking through the 107 instance of
>>>> ConcurrentHashMap, I
>>>> found one *really* big one: Localizer.cache has a hash table  
>>>> length of
>>>> 262144, each of its 32 segments with about 5300 entries, where a  
>>>> hash key
>>>> is
>>>> a string, sometimes longer than 500 charactes, similar to (see
>>>> Localizer.getCacheKey(String,Component)):
>>>>
>>>> fooTitle.bar- 
>>>> org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- 
>>>> org.apache.wicket.markup.html.panel.Fragment:track- 
>>>> org.apache.wicket.markup.html.list.ListItem:14- 
>>>> my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- 
>>>> org.apache.wicket.markup.html.list.ListItem:0- 
>>>> my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- 
>>>> my.company.boxes.BodyBox:2- 
>>>> org.apache.wicket.markup.repeater.RepeatingView:body- 
>>>> my.company.layout.Border:border-my.company.pages.music.FoobarPage: 
>>>> 43-de-null
>>>>
>>>> Those numbers pretty much convinced me: The localizer cache has  
>>>> blown
>>>> away
>>>> my application.
>>>>
>>>> Looking at this hash keys, I suspect the following problem: those  
>>>> strings
>>>> are constructed from the "position" of a localized String on a page,
>>>> which
>>>> is quite a bad thing if you use nested list views or repeating  
>>>> views to
>>>> construct your page. For instance, I have a panel with a long  
>>>> (pageable)
>>>> list of entries, might be > 5000 entries which might appear on  
>>>> various
>>>> positions in a repeating view I use as a container for most of my  
>>>> pages.
>>>> Let's say there are 5 possible positions, this would cause 2500  
>>>> thousand
>>>> cached entries, each with a key of 300+ characters plus some more
>>>> characters
>>>> for the cached message - feel free to do the maths. From a quick  
>>>> estimate
>>>> I'd say: No wonder, this has blown away my app.
>>>>
>>>> As a quick fix, I'd suggest to regularly clear the localizer  
>>>> cache, use a
>>>> more sophisticated cache (that expires old entries once

Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-10 Thread Stefan Fußenegger


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this fix gets
into the next maintenance release. I am to lazy to create a properly patched
jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:
> 
> try applying this patch and see if it helps
> 
> https://issues.apache.org/jira/browse/WICKET-1667
> 
> -igor
> 
> On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> I am just analysing a heap dump (god bless the
>> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due
>> to
>> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using
>> jhat, the "175456 instances of class
>> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately
>> got
>> my attention. While looking through the 107 instance of
>> ConcurrentHashMap, I
>> found one *really* big one: Localizer.cache has a hash table length of
>> 262144, each of its 32 segments with about 5300 entries, where a hash key
>> is
>> a string, sometimes longer than 500 charactes, similar to (see
>> Localizer.getCacheKey(String,Component)):
>>
>> fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null
>>
>> Those numbers pretty much convinced me: The localizer cache has blown
>> away
>> my application.
>>
>> Looking at this hash keys, I suspect the following problem: those strings
>> are constructed from the "position" of a localized String on a page,
>> which
>> is quite a bad thing if you use nested list views or repeating views to
>> construct your page. For instance, I have a panel with a long (pageable)
>> list of entries, might be > 5000 entries which might appear on various
>> positions in a repeating view I use as a container for most of my pages.
>> Let's say there are 5 possible positions, this would cause 2500 thousand
>> cached entries, each with a key of 300+ characters plus some more
>> characters
>> for the cached message - feel free to do the maths. From a quick estimate
>> I'd say: No wonder, this has blown away my app.
>>
>> As a quick fix, I'd suggest to regularly clear the localizer cache, use a
>> more sophisticated cache (that expires old entries once in a while!!) or
>> to
>> disable the cache completely. However, don't try to overwrite
>> Localizer.newCache() and clear the cache regularly: clearCache() will
>> replace your cache with a ConcurrentHashMap (not using
>> Localizer.newCache()). However, quite unlikely, that this will happen as
>> newCache() is private anyway ;) I am going to add some code to clear the
>> cache regularly.
>>
>> Best regards, Stefan
>>
>> PS: I'll also create a JIRA issue, but I am really short on time right
>> now.
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17751273.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]

Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-09 Thread Stefan Fußenegger


I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to
an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using
jhat, the "175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately got
my attention. While looking through the 107 instance of ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table length of
262144, each of its 32 segments with about 5300 entries, where a hash key is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null

Those numbers pretty much convinced me: The localizer cache has blown away
my application. 

Looking at this hash keys, I suspect the following problem: those strings
are constructed from the "position" of a localized String on a page, which
is quite a bad thing if you use nested list views or repeating views to
construct your page. For instance, I have a panel with a long (pageable)
list of entries, might be > 5000 entries which might appear on various
positions in a repeating view I use as a container for most of my pages.
Let's say there are 5 possible positions, this would cause 2500 thousand
cached entries, each with a key of 300+ characters plus some more characters
for the cached message - feel free to do the maths. From a quick estimate
I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer cache, use a
more sophisticated cache (that expires old entries once in a while!!) or to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache() will
replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will happen as
newCache() is private anyway ;) I am going to add some code to clear the
cache regularly.

Best regards, Stefan

PS: I'll also create a JIRA issue, but I am really short on time right now.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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: Use Spring with Wicket

2008-06-03 Thread Stefan Fußenegger


Martijn Dashorst compiled a nice list of books (3 for beginners, another 3 on
advanced topics) that will certainly help you to get started:

http://martijndashorst.com/blog/2008/05/25/wicket-starter-kit/

Regards


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17619622.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

2008-06-03 Thread Stefan Fußenegger


1) Generifying* Wicket
   [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.

2) How strongly do you feel about your choice above?
   [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.

I didn't read all of the posts here, but I would suggest to go for Component
or even @SuppressWarnings("unchecked"). This way, you don't have to use
generified components but are still able to do so. Currently, I am always
passing models as parameter to the constructor of my custom components.
Those parameters are always named according to the expected type they
contain (e.g. fooModel if i expect an object of type Foo in there).
Therefore, generics could jump in quite easily and I am looking forward to
use them!

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17618096.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: Memory leak in DiskPageStore

2008-06-02 Thread Stefan Fußenegger


https://issues.apache.org/jira/browse/WICKET-1679


Matej Knopp-2 wrote:
> 
> Hi,
> 
> about not removing the entries, can you please create jira issue? I
> will try to look into it ASAP.
> 
> -Matej
> 
> On Mon, Jun 2, 2008 at 11:38 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>> Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
>> priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to
>> look
>> at (one crash was due to a GC overhead exception, so no dump there). One
>> thing that immediately attracted my attention was that there were 116.917
>> instances of
>> org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
>> objects of this class "represent a session" (javadoc), it seems that I
>> had
>> 116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.
>>
>> In my app, i spotted two reasons for this;
>> 1. search engine bots (e.g. googlebot) receive a new session for each
>> page
>> they access, as we cut of the ;jsessionid= from the URL in our app in
>> order
>> not to have those ugly IDs on the search engine result pages. As a
>> result,
>> when google tried to index 100.000+ pages 100.000+ sessions had been
>> created. I am certainly going to work on this issue, however, it helped
>> me
>> to spot reason number 2:
>>
>> 2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I
>> guess,
>> this should be added to the DiskPageStore.unbind(String sessionId)
>> method:
>>
>>public void unbind(String sessionId)
>>{
>>// FIX: replace get() with remove()
>>SessionEntry entry =
>> (SessionEntry)sessionIdToEntryMap.get(sessionId);
>>if (entry != null)
>>{
>>if (isSynchronous())
>>{
>>entry.unbind();
>>}
>>else
>>{
>>List pages =
>> getPagesToSaveList(sessionId);
>>synchronized (pages)
>>{
>>        flushPagesToSaveList(sessionId,
>> pages);
>>entry.unbind();
>>}
>>pagesToSaveAll.remove(sessionId);
>>}
>>}
>>}
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597859.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]

Memory leak in DiskPageStore

2008-06-02 Thread Stefan Fußenegger


Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to look
at (one crash was due to a GC overhead exception, so no dump there). One
thing that immediately attracted my attention was that there were 116.917
instances of
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
objects of this class "represent a session" (javadoc), it seems that I had
116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.

In my app, i spotted two reasons for this;
1. search engine bots (e.g. googlebot) receive a new session for each page
they access, as we cut of the ;jsessionid= from the URL in our app in order
not to have those ugly IDs on the search engine result pages. As a result,
when google tried to index 100.000+ pages 100.000+ sessions had been
created. I am certainly going to work on this issue, however, it helped me
to spot reason number 2:

2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I guess,
this should be added to the DiskPageStore.unbind(String sessionId) method:

public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry = 
(SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages = getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId, pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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: How to avoid Lazy loading exception

2008-05-04 Thread Stefan Fußenegger


Do you have OpenSessionInViewFilter in your web.xml? If no, you will get this
exception whenever you try to do lazy loading outside your DAOs.

add to web.xml:
  
OpenSessionFilter

  org.springframework.orm.hibernate3.support.OpenSessionInViewFilter


  sessionFactoryBeanName
  hibernateSessionFactory

  

  
OpenSessionFilter
/*
  

I always use a self-written class called PersistentObjectModel (a
LoadableDetachableModel) and let all my Persisent classes implement an
interface called IPersistentObject with a single method: Serializable
getId()

public class PersistentObjectModel extends
LoadableDetachableModel {

private static final long serialVersionUID = 1L;

private final Class _clazz;

private final int _id;

@SpringBean(name = "myDao")
private IMyDao _myDao;

@SuppressWarnings("unchecked")
public PersistentObjectModel(final T object) {
super(object);

if (object instanceof HibernateProxy) {
_clazz = (Class) ((HibernateProxy)
object).getHibernateLazyInitializer()
.getImplementation().getClass();
} else {
_clazz = (Class) object.getClass();
}
_id = object.getId();
// inject the bean
InjectorHolder.getInjector().inject(this);
}

public PersistentObjectModel(final Class clazz, final int id) {
_clazz = clazz;
_id = id;
// inject the bean
InjectorHolder.getInjector().inject(this);
}

@Override
protected T load() {
return _myDao.getById(_clazz, _id);
}

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

}


This makes working with hibernate objects really easy:

setModel(new PersistentObjectModel(Foo.class, 1)); // option 1: class and id
setModel(new PersistentObjectModel(foo)); // option 2: persistent object

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/How-to-avoid-Lazy-loading-exception-tp17040941p17045620.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]

Wicket fail-over with Terracotta - sticky or non-sticky sessions?

2008-04-03 Thread Stefan Fußenegger


Hi all,

I am currently evaluating a Wicket fail-over solution (two equal nodes with
a floating IP, probably using Linux Heartbeat) with Terracotta. Of course,
it would be desirable to switch between nodes without any impact on a user's
session. In order to provide this, the cluster must be able to handle
non-sticky sessions. Session clustering works like a breeze with Wicket and
Terracotta

I already spotted a problem with buffered redirects, that could be avoided
with a different rendering strategy
(IRequestCycleSettings.REDIRECT_TO_RENDER). However, this problem would only
occur if a node goes down just when the client is redirecting - not very
likely and probably acceptable as switching over might take a few seconds
anyway.

Now my question: What other problems could appear when I only use session
clustering for fail-over purposes? Can I stay with the default rendering
strategy (IRequestCycleSettings.REDIRECT_TO_BUFFER) without clustering the
buffer if I accept missing feedback messages in the above scenario?

Any further comments on my setup will be appreciated as well!

(If answers are woth it, I'll create a wiki page out of this thread)

Best Regards, Stefan


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-fail-over-with-Terracotta---sticky-or-non-sticky-sessions--tp16467830p16467830.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: Accessing prototype scoped panel beans using @SpringBean annotation


What do you mean by "directly"? Do you want to inject the panels rather than
the factories? You could probably try to write your own annotation and use a
custom org.apache.wicket.injection.IFieldValueFactory



Ned Collyer wrote:
> 
> 
> Stefan Fußenegger wrote:
>> 
>> Hi Tom,
>> 
>> I'd suggest not to use Spring to manage panels. You should rather create
>> a new panel for every page and request. You should use Spring to manage
>> your services and inject those into your panels.
>> 
>> Best regards, Stefan
>> 
> 
> Hi Stephan :) (I work with Tom)
> 
> We have a work around for this specific problem, and it still involves
> spring, but not using panels directly.
> 
> Basically the situation is as follows.
> 
> We have a main wicket project which is published as a jar.
> 
> There are also other modules also published as "plugin" jars.
> 
> We launch these with an embedded jetty instance.
> 
> The problem is the Main project contains the page instances, and the other
> jars contain the panels.
> 
> The Main project has no idea about which panels are available, as these
> will be determined at run time by whatever has been configured (thru
> spring).  The main jar has no knowledge of which panel classes exist - so
> we cannot really instantiate new ones using plain old java.
> 
> There are a few ways to approach this, ie, having some class loader which
> resolves given string "class references", and those strings are wired in
> through spring.  This works - but feels a bit hacky.
> 
> Our workaround is .. somewhat similar - we basically have a panel factory
> in the plugin that instantiate a panel and return it.  We can then wire
> these panel factories thru spring to a given page.
> 
> This turns out to be quite elegant - however it would be nice if we had
> the ability to wire "plugin" panels to the main jar directly without this
> factory.
> 
> Rgds
> 
> Ned
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15632905.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: how to create the component dynamic?


Hi Mead,

I'd say that wicket is a real cool choice to accomplish this (I know what
I'm talking about as I hacked such a tool in PHP years ago in my programming
infancy ;) )

There is no general answer though. But for different question types you
could do

if (type == DROP_DOWN_QUESTION) add(new DropDownQuestionPanel("panel",
question);
else if (type == RADIO_QUESTION) add(new RadioQuestionPanel("panel",
question);
// you got the idea

you could also create the panels dynamically by giving a type such as
"com.foo.questiontype.DropDown" using reflection. This way you could create
a quite flexible solution, where you could drop in just another jar to add
new question types.

If it comes to different numbers of possibilities, RepeatingView might be a
good choice.

Best regards and good luck




Mead-2 wrote:
> 
>  Well, I wanne build a Survey-System!
> Now there're some Questions in the Survey-System, and will default some
> answer-item for user to choice!
> following is the example of Question
> 1,It's the weather good today?(A.B.C. would be radio)
>   A.yes, Sunny
>   B.no, Rainy
>   C.so so
> I think all the component shall be created at run time! but some question
> has 5 items some has 3 items,
> some is a TextField which filled by user, some is CheckBox or Radio.
> How to do with this?
> 
> Mead
> 
>  
>  
>  
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/how-to-create-the-component-dynamic--tp15630091p15631519.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: Accessing prototype scoped panel beans using @SpringBean annotation

vailable(HttpParser.java:210)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> 
> Complete stack:
> 
> org.apache.wicket.WicketRuntimeException: Error attaching this container
> for rendering: [Page class = com.example.TestPage, id = 0, version = 0]
> at
> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1525)
> at org.apache.wicket.Component.onBeforeRender(Component.java:3657)
> at org.apache.wicket.Page.onBeforeRender(Page.java:1402)
> at org.apache.wicket.Component.internalBeforeRender(Component.java:995)
> at org.apache.wicket.Component.beforeRender(Component.java:1027)
> at org.apache.wicket.Component.prepareForRender(Component.java:2139)
> at org.apache.wicket.Page.renderPage(Page.java:870)
> at
> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:231)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103)
> at
> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241)
> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316)
> at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
> at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
> 
> 
> Can anyone throw some light on what I'm doing wrong.  I'm not tied to the
> idea of the Panels being prototype beans however without it, immediately
> on server startup, I get a "WicketRuntimeException: There is no
> application attached to current thread main".  Making them prototype seems
> to be the only way for me to get my server to startup cleanly.
> 
> Thanks,
> Tom.
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15631515.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]

usage of AbortWithHttpStatusException


Hi,

How is AbortWithHttpStatusException meant to be used? I expected that this
exception would result in a (e.g.) 404 error page to be shown. However, all
I get is an empty page. Any ideas on how I can get a nice, custom error page
to show up?

Cheers, Stefan

btw: i'm using jetty if this is important.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/usage-of-AbortWithHttpStatusException-tp15631513p15631513.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: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger


I was just waiting for green lights ;)

https://issues.apache.org/jira/browse/WICKET-1363


igor.vaynberg wrote:
> 
> feel free to add a jira request for this
> 
> -igor
> 
> 
> On Thu, Feb 21, 2008 at 4:44 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>>  Maurice,
>>
>>  Thanks for your suggestions. However, these suggestions are yet 2 other
>>  workarounds for this problem.
>>
>>  imho, using RestartResponseAtInterceptPageException and
>>  continueToOriginalDestination() should work out of the box, regardless
>> of
>>  the type of request (Ajax and non-Ajax). Therefore I suggest adding
>> support
>>  to the framework - and your suggestions did not convince me not to do
>> so,
>>  sorry ;)
>>
>>  However, the strategy to choose a page for
>> continueToOriginalDestination()
>>  is open for discussion. The simplest approach would be to go back to the
>>  source of the Ajax request, while allowing to complete the request and
>>  render the entire page afterwards would be best.
>>
>>  -- Stefan
>>
>>
>>
>>
>>
>>  Mr Mean wrote:
>>  >
>>  > Hmm, i'm not sure this will work at all with the restartresponse but i
>>  > have 2 alternatives that do not require changes to wicket
>>  >
>>  > -append some javascript to the ajaxrequesttarget that will trigger the
>>  > browser to request your login page (you can get the wicket url for the
>>  > loginpage using urlFor)
>>  >  if your login page accepts pageparams you can use those to decide
>>  > what the response for a successful login should be.
>>  >
>>  > -open you login page in a ModalWindow on the same page and close it
>>  > after a successful login (you might need to refresh the origin page
>>  > after this)
>>  >
>>  > Maurice
>>  >
>>  > On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
>>  > <[EMAIL PROTECTED]> wrote:
>>  >>
>>  >>  Hi,
>>  >>
>>  >>  I'm currently trying to use RestartResponseAtInterceptPageException
>> with
>>  >>  Ajax. More precisely, I show a component that refreshes itself after
>>  >>  executing an authorized action. It the user is not authorized to
>> execute
>>  >>  this action, I'd like to redirect him to the Login-Page. After
>> proper
>>  >> login,
>>  >>  the user should be redirected to the original page. However, using
>>  >>  continueToOriginalDestination() does not work (out of the box), as
>> the
>>  >> User
>>  >>  is redirected to the URL of the Ajax request.
>>  >>
>>  >>
>>  >>  Workaround/Possible changes to simplify workaround:
>>  >>
>>  >>  A custom workaround would be to do a custom PageMap implementation.
>>  >> However,
>>  >>  as the method setUpRedirect(RequestCycle) is private, deriving from
>> the
>>  >>  default PageMap will require some ugly copy-paste in order to do so.
>>  >> This
>>  >>  could be avoided by a) making setUpRedirect(RequestCycle) protected
>>  >> and/or
>>  >>  b) introduce a protected method that constructs the
>>  >> interceptContinuationURL
>>  >>  inside setUpRedirect(RequestCycle).
>>  >>
>>  >>
>>  >>  Changing default behaviour:
>>  >>
>>  >>  The workaround version is not trivial, as in requires quite a bit of
>>  >>  knowledge of Wicket's inner workings ("What the hell is a
>> PageMap?").
>>  >>  Therefore, it might be a good idea to change the default behaviour
>>  >> there, as
>>  >>  no user wants to see Ajax responses at all (well, at least no normal
>>  >> user -
>>  >>  I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour
>> be
>>  >>  somewhat more intelligent by default (without hacking a custom
>> PageMap)?
>>  >>  That is to redirect to the page the Ajax request belonged to? Or
>> even
>>  >>  better: redirect to the Ajax call and render the complete page
>> (well,
>>  >> don't
>>  >>  know how tricky that would be).
>>  >>
>>  >>  Or do I miss something completely? Any other possible workarounds or
>>  >>  suggestions?
>>  >>
>>  >>  Cheers, Stefan
>>  >>
>>  >>  -
>>  >>  ---
>&g

Re: RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger


Maurice, 

Thanks for your suggestions. However, these suggestions are yet 2 other
workarounds for this problem.

imho, using RestartResponseAtInterceptPageException and
continueToOriginalDestination() should work out of the box, regardless of
the type of request (Ajax and non-Ajax). Therefore I suggest adding support
to the framework - and your suggestions did not convince me not to do so,
sorry ;)

However, the strategy to choose a page for continueToOriginalDestination()
is open for discussion. The simplest approach would be to go back to the
source of the Ajax request, while allowing to complete the request and
render the entire page afterwards would be best.

-- Stefan



Mr Mean wrote:
> 
> Hmm, i'm not sure this will work at all with the restartresponse but i
> have 2 alternatives that do not require changes to wicket
> 
> -append some javascript to the ajaxrequesttarget that will trigger the
> browser to request your login page (you can get the wicket url for the
> loginpage using urlFor)
>  if your login page accepts pageparams you can use those to decide
> what the response for a successful login should be.
> 
> -open you login page in a ModalWindow on the same page and close it
> after a successful login (you might need to refresh the origin page
> after this)
> 
> Maurice
> 
> On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger
> <[EMAIL PROTECTED]> wrote:
>>
>>  Hi,
>>
>>  I'm currently trying to use RestartResponseAtInterceptPageException with
>>  Ajax. More precisely, I show a component that refreshes itself after
>>  executing an authorized action. It the user is not authorized to execute
>>  this action, I'd like to redirect him to the Login-Page. After proper
>> login,
>>  the user should be redirected to the original page. However, using
>>  continueToOriginalDestination() does not work (out of the box), as the
>> User
>>  is redirected to the URL of the Ajax request.
>>
>>
>>  Workaround/Possible changes to simplify workaround:
>>
>>  A custom workaround would be to do a custom PageMap implementation.
>> However,
>>  as the method setUpRedirect(RequestCycle) is private, deriving from the
>>  default PageMap will require some ugly copy-paste in order to do so.
>> This
>>  could be avoided by a) making setUpRedirect(RequestCycle) protected
>> and/or
>>  b) introduce a protected method that constructs the
>> interceptContinuationURL
>>  inside setUpRedirect(RequestCycle).
>>
>>
>>  Changing default behaviour:
>>
>>  The workaround version is not trivial, as in requires quite a bit of
>>  knowledge of Wicket's inner workings ("What the hell is a PageMap?").
>>  Therefore, it might be a good idea to change the default behaviour
>> there, as
>>  no user wants to see Ajax responses at all (well, at least no normal
>> user -
>>  I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
>>  somewhat more intelligent by default (without hacking a custom PageMap)?
>>  That is to redirect to the page the Ajax request belonged to? Or even
>>  better: redirect to the Ajax call and render the complete page (well,
>> don't
>>  know how tricky that would be).
>>
>>  Or do I miss something completely? Any other possible workarounds or
>>  suggestions?
>>
>>  Cheers, Stefan
>>
>>  -
>>  ---
>>  Stefan Fußenegger
>>  http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>  --
>>  View this message in context:
>> http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]

RestartResponseAtInterceptPageException with Ajax

2008-02-21 Thread Stefan Fußenegger

Hi,

I'm currently trying to use RestartResponseAtInterceptPageException with
Ajax. More precisely, I show a component that refreshes itself after
executing an authorized action. It the user is not authorized to execute
this action, I'd like to redirect him to the Login-Page. After proper login,
the user should be redirected to the original page. However, using
continueToOriginalDestination() does not work (out of the box), as the User
is redirected to the URL of the Ajax request.

Workaround/Possible changes to simplify workaround:

A custom workaround would be to do a custom PageMap implementation. However,
as the method setUpRedirect(RequestCycle) is private, deriving from the
default PageMap will require some ugly copy-paste in order to do so. This
could be avoided by a) making setUpRedirect(RequestCycle) protected and/or
b) introduce a protected method that constructs the interceptContinuationURL
inside setUpRedirect(RequestCycle).

Changing default behaviour:

The workaround version is not trivial, as in requires quite a bit of
knowledge of Wicket's inner workings ("What the hell is a PageMap?").
Therefore, it might be a good idea to change the default behaviour there, as
no user wants to see Ajax responses at all (well, at least no normal user -
I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be
somewhat more intelligent by default (without hacking a custom PageMap)?
That is to redirect to the page the Ajax request belonged to? Or even
better: redirect to the Ajax call and render the complete page (well, don't
know how tricky that would be).

Or do I miss something completely? Any other possible workarounds or
suggestions?

Cheers, Stefan

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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: (Server-independent) Comet support in Wicket?

2008-02-20 Thread Stefan Fußenegger


wicketstuff-push might be what you are looking for: wicket cometd support
with jetty. but i don't think that anybody has used it with 10k simultaneous
users yet.

see:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/



Jörn Zaefferer-2 wrote:
> 
> Hi,
> 
> I've started evaluating Wicket today for an application written from
> scratch. First impressions are very well, there is just one
> requirement on which I couldn't find enough useful information yet:
> Comet support in Wicket or Comet with Wicket.
> 
> Before looking at Wicket I tried to use lift which has Comet support
> built in (based on Scala Actors). This post
> (http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html)
> suggests that its not possible to implement scaleable Comet support
> within a web framework, instead it must be supported by the
> application server, eg. Jetty 6.
> 
> Post about Comet and Wicket, eg. this one
> (http://www.mail-archive.com/[EMAIL PROTECTED]/msg17308.html)
> don't give me any actual information about the current state of afairs
> (its from 2006, the linked sf.net issue is now private). This issue
> (http://wicketstuff.org/jira/browse/DOJO-23) about integration with
> cometd isn't too helpful either, I can't find any documentation on
> that.
> 
> To provide some information on the actual requirements I have: The
> architecture must support several both dependent and independent
> components on a single page which get updated based on server-events,
> be it on schedules or events triggered by other users. While the exact
> number of simultaneous users isn't clear yet, up to 10k must be
> possible with the appropriate hardware.
> 
> Thanks
> Jörn Zaefferer
> 
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/%28Server-independent%29-Comet-support-in-Wicket--tp15574656p15589149.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: Minor Announcement: wicket-googlecharts

2007-12-21 Thread Stefan Fußenegger


Hi Daniel,

Last week I did exactly the same as you did here and was also planing to
release it as wicketstuff project ... i think this could be called bad
timing ;)

Maybe we could collaborate on this in the future (I'll have a closer look
after Christmas and maybe merge my stuff with yours)

Regards, Stefan


Daniel Spiewak wrote:
> 
> Just a minor sidebar, at Johan's suggestion I've released
> wicket-googlecharts into the wicket-stuff project.  I played with the
> build
> system a bit to make it work with maven and I think I did it right, but my
> maven experience is limited.  License is currently discretionary, though
> if
> I really had to pick one I'd probably go with either ASL2 or BSD.
> 
> Warning: anything that isn't tested by the test page in the project is
> completely theoretical and untested.  This means things like scatter
> plots,
> color fills, etc are all up in the air.  I'll probably get around to
> stabilizing functionality eventually, but for now it can just float.
> Hopefully someone will find this useful!
> 
> Daniel
> 
> (original article:
> http://www.codecommit.com/blog/java/a-wicket-api-for-google-charts)
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Minor-Announcement%3A-wicket-googlecharts-tp14442165p14454946.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: Attempted summary of multiple thread

2007-11-11 Thread Stefan Fußenegger

;> A) If you don't 'extend' a 'child' section in a derived page wicket uses
>> the child section provided in the base page.
>>
>> (Comment: Extend a child? We're not extending the child section - we're
>> replacing it!)
>>
>> B) If you don't 'extend' a 'default' section in a derived page wicket
>> uses the default section provided in the base page.
>>
>> (Comment: Extend? It is the page you are extended by overriding one or
>> more of its default sections. Again you aren't extending a default
>> section you are replacing it!)
>>
>> Or even - now I'm really pushing my luck asking to provide two aliases
>> ;)
>>
>> C) If you don't 'override' a 'default' section in a derived page wicket
>> uses the 'default' section provided in the base page.
>>
>> (Comment - arrhh beautiful - 100% accurate and natural)
>>
>> At university I remember a lecturer telling a story of an interview with
>> one of the creators of Unix. He was asked if he had any regrets over his
>> illustrious career and he said "Yes I do, I regret naming the 'create'
>> function 'creat' instead of 'create' just to save one byte!". How much
>> frustration does a bad name cause?
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Bruno Borges
> blog.brunoborges.com.br
> +55 1185657739
> 
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13690139
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: Attempted summary of multiple thread

2007-11-09 Thread Stefan Fußenegger


Of course, it really is optional. Wicket only checks whether a page has a
 tag or not to decide if markup merging is needed.
(Therefore, my patch does not have any impact on that, as there is no markup
merging triggered)

Thanks for pointing this out!

-- stefan



Sebastiaan van Erk wrote:
> 
> Hi,
> 
> Actually, Wicket already works like this. It does *NOT* require the 
> , and if it's not present it just renders the contents of 
> the . (Just tested this with beta4).
> 
> Furthermore, your patch works exactly the same as far for multilple 
> child sections (as far as I can tell, or otherwise it should for 
> backwards compatibility), and does precisely what both you and Chris want.
> 
> Regards,
> Sebastiaan
> 
> Stefan Fußenegger wrote:
>> I think it would be a nice feature to define defaults and overrides this
>> way.
>> However, this wouldn't be backwards compatible anymore as the contents
>> are
>> currently ignored. (Ok, you are currently forced to extend them, so you
>> probably wouldn't see the markup from such sections in *old*
>> applications.)
>> 
>> My vote on this:
>> - I would love to have multiple sections.
>> - I would appreciate default markup for extendible sections.
>> 
>> Kind regards,
>> 
>> -- stefan
>> 
>> PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)
>> 
>> 
>> 
>> Chris Colman wrote:
>>>> That is what I'd suggest as well, since it involves the least amount
>>> of
>>>> change. As an added bonus, if no id's are added and 2 
>>>> sections are used, it could throw an exception (which it currently
>>> does
>>>> not do, it just silently ignores the second ).
>>> That would be magic!
>>>
>>> While we're at this epic moment after spending days thrashing this out
>>> could we spend just 3 extra minutes to investigate implementing standard
>>> Java method like behavior for this feature?
>>> Ie., In the case that no override  is provided in a derived
>>> page, simply use the markup in the  tag in the base page.
>>>
>>> Then it would work like methods work in Java - and it's probably how
>>> most Java developers would naturally expect an OO framework like wicket
>>> to work anyway.
>>>
>>> Intuitively it seems like an easy to implement option in the framework:
>>> the / feature is already merging code from the base page
>>> anyway - if there is no override  tag in a derived page then it
>>> simply pulls the markup from the base page's  tag.
>>>
>>>> Regards,
>>>> Sebastiaan
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>> 
>> 
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> 
>  
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078
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: facebook support

2007-11-09 Thread Stefan Fußenegger

I'd be interested in Facebook and Open Social support. However, I don't have
any experience with either of them.

It would be extremely cool to have a common interface for both of them -
write once run everywhere.

I would also help implementing it. I don't have much time to spend tough.
For my project, facebook and open social support won't be required within
the next 6 month. (But it would be cool to have.)

-- Stefan

Jonathan Locke wrote:
> 
> I'd like to get facebook support into Wicket.  If anyone out there has
> interest and would like to cooperate(particularly anyone with Facebook
> experience), please get in touch with me.  Thanks.
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/facebook-support-tf4773546.html#a13662919
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: Attempted summary of multiple thread

2007-11-09 Thread Stefan Fußenegger


I think it would be a nice feature to define defaults and overrides this way.
However, this wouldn't be backwards compatible anymore as the contents are
currently ignored. (Ok, you are currently forced to extend them, so you
probably wouldn't see the markup from such sections in *old* applications.)

My vote on this:
- I would love to have multiple sections.
- I would appreciate default markup for extendible sections.

Kind regards,

-- stefan

PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)



Chris Colman wrote:
> 
>> That is what I'd suggest as well, since it involves the least amount
> of
>> change. As an added bonus, if no id's are added and 2 
>> sections are used, it could throw an exception (which it currently
> does
>> not do, it just silently ignores the second ).
> 
> That would be magic!
> 
> While we're at this epic moment after spending days thrashing this out
> could we spend just 3 extra minutes to investigate implementing standard
> Java method like behavior for this feature?
> Ie., In the case that no override  is provided in a derived
> page, simply use the markup in the  tag in the base page.
> 
> Then it would work like methods work in Java - and it's probably how
> most Java developers would naturally expect an OO framework like wicket
> to work anyway.
> 
> Intuitively it seems like an easy to implement option in the framework:
> the / feature is already merging code from the base page
> anyway - if there is no override  tag in a derived page then it
> simply pulls the markup from the base page's  tag.
> 
>> 
>> Regards,
>> Sebastiaan
> 
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13662915
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: Attempted summary of multiple thread

2007-11-08 Thread Stefan Fußenegger


Hi eelco.

Did you see what I changed in order to make this working? There is nearly no
extra complexity. So I think complexity isn't an argument here.

best regards

-- stefan




Eelco Hillenius wrote:
> 
>> In conclusion, the proposed change:
>> - is useful
>> - does not have to be used if you don't like it
>> - is 100% backwards compatible
>> - it introduces no new tags (if using child/extends)
> 
> The thing is though, even though it is 100% backwards compatible, it
> is something we'll have to support. It adds complexity to the
> implementation, and we'll have to answer questions about it on the
> list. That would be fine if everyone would have been wildly
> enthusiastic about it, but that is not the case - whether you think
> that is justified or not.
> 
> So, like I propose in the main thread, the best way to go is to
> implement this as a separate project, using separate tags. We'll be
> happy to support any internal API changes if that is needed to make
> the implementation work. The advantage of having this separate project
> is that such inheritance would be available for people who like it,
> and hey, maybe in the longer term you have something that works so
> good that you can convince people based on something that works.
> Executable code works much better than simply words when it comes to
> that ;-)
> 
> Do people want to work on this?
> 
> Regards,
> 
> Eelco
> 
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13643264
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: Multiple tags on a single base page?

2007-11-08 Thread Stefan Fußenegger

hi eelco,

Assume the tag wouldn't be renamed. Then it would only be a new and optional
(!) attribute for the child/extend tags. So isn't it unnecessary to
explicitly turn on/off a feature that you could implicitly turn on as soon
as this attribute is used?

The naming - is abstract/implement better than child/extend - is another
topic I really didn't want to argue about.

This is just an idea. I know that supporting it as wicket core feature
(docs, mailing list, code, ...) is a totally different question.

regards, stefan

100th reply - is it a Good Thing (tm) ;)

Eelco Hillenius wrote:
> 
> On Nov 7, 2007 11:19 AM, Scott Swank <[EMAIL PROTECTED]> wrote:
>> I can see how  and  tags could be
>> a nice enhancement to the current  and 
>> tags.  Do you have a working, or mostly working, patch?
> 
> What I think we should do with this is make it an option. It would be
> turned off by default, requiring users to an extra one or two lines of
> configuration to turn this on (we've done this before), and let it
> prove itself. Sounds to me like everyone would be happy.
> 
> WDYT?
> 
> Eelco
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13643104
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: Multiple tags on a single base page?


Yes!

see: https://issues.apache.org/jira/browse/WICKET-1134

-- stefan 


Scott Swank wrote:
> 
> I can see how  and  tags could be
> a nice enhancement to the current  and 
> tags.  Do you have a working, or mostly working, patch?
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13634545
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: Multiple tags on a single base page?


But the number of added panels needn't be the number of abstract section
(though it could). 

-- stefan 


Jan Kriesten wrote:
> 
> 
> hi stefan,
> 
>> And if somebody really needs 5 child areas, something else might be even
>> messier than the page's constructor. I rather think that 2, 3 or in rare
>> cases even 4 ids could make sense.
> 
> i must disagree - i have a basepage which defines the default layout on a
> project, i.e. header, top-nav-container (imprint etc), navigation,
> content-left/-right/main, footer - this makes 7 panels which are added on
> the
> way down to the resulting page...
> 
> but i don't use abstract methods for this, for it can get messy (as stated
> in
> other comments).
> 
> regards, --- jan.
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631624
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: Multiple tags on a single base page?


>From the Java-side, it isn't visible, whether a component will be placed in
whatever html part. So you add all components in the constructor, yes.
However, it's as messy as adding 5 components is right now ... they will
just be added at different places.

And if somebody really needs 5 child areas, something else might be even
messier than the page's constructor. I rather think that 2, 3 or in rare
cases even 4 ids could make sense.

Is that what you meant?

-- stefan


Johan Compagner wrote:
> 
> no not the merging of markup.
> but inside the constructor of the child/sub page.
> Where do you make all the root components of all the child parts?
> you will add that to the page itself right?
> 
> I just say that then it could be a bit messy when you have 5 child area's
> 
> johan
> 
> 
> 
> On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>>
>>
>> hi johan,
>>
>>
>> Johan Compagner wrote:
>> >
>> > 1 thing that does bother me a bit (but maybe i have to do a deeper look
>> > into
>> > the patch) how do you separate
>> > the components in the constructor of the sub page.. i guess you just
>> add
>> > all
>> > the components over all the child fragments
>> > in the page itself. That's not a nice separation... That can lead to
>> big
>> a
>> > big mess.. Because what component belong to what child part. "
>> >
>>
>> I don't get what you mean here. However, my implementation is closely
>> related to Juergen's MergedMarkup.java (and admittedly partially copied)
>> and
>> does the same.
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631363
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: Multiple tags on a single base page?


hi johan,


Johan Compagner wrote:
> 
> 1 thing that does bother me a bit (but maybe i have to do a deeper look
> into
> the patch) how do you separate
> the components in the constructor of the sub page.. i guess you just add
> all
> the components over all the child fragments
> in the page itself. That's not a nice separation... That can lead to big a
> big mess.. Because what component belong to what child part. "
> 

I don't get what you mean here. However, my implementation is closely
related to Juergen's MergedMarkup.java (and admittedly partially copied) and
does the same.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
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: Multiple tags on a single base page?


Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name




some text


and remember that they can be optional as well:




some text


This way, its completely compatible with child/extend (which can be proofed
with the existing junit test for markup inheritance)

just a question: do i start to convince you? ;)

best regards


Bruno Borges wrote:
> 
> Let me paste what I commented in WICKET-1134:
> 
> *I think this improvement is just more of a way to "override" components
> declared in markups of a super class. Because this is what really happens.
> Let's check your example:
> 
> In the BasePage, there are two fragments:
> - subNavigation
> - content
> 
> What about if I want to have a fragment in SectionPage with id "content",
> but not related with that content from BasePage? You see, the concept of
> extend/child, is the same as in OOP's inheritance. What goes in child, is
> from the subclass. Period.
> 
> In Java, if you declare:
> class BasePage ... {
> protected Object someProperty;
> }
> 
> class SectionPage extends BasePage {
> protected Object someProperty;
> }
> 
> What happens here is that SectionPage.someProperty does NOT
> override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> you
> want to do in HTML would be this in Java.
> 
> I'm worry about people trying to subclass some WebMarkupContainer, and
> having to be carefully with components ids, just to _not_ match something
> that would generate strange output.
> 
> If in SectionPage I add some component (like Label) with "content" id,
> what
> would happen? Throw a message: "You cannot use this id because there's an
> abstract 'content' markup in BasePage.html". This would lead to code in
> HTML
> that has NO reference within it's Java class.
> 
> This means that: what you don't see in Java, it *might* be possible to
> exist
> in the HTML.
> 
> And what I like most of Wicket, is its ability to let me take control of
> everything, just from one source: Java. But if I'm going to be obligated
> of
> taking care of what people declare in HTML files that I can't see in some
> Java source code, then I will reconsider my framework's choice.
> 
> Regards*
> 
> Now, Stefan, let me reply your last comment in the issue:
> *No, ids used with abstract/implement are completely different from
> wicket:ids ... they are only used to construct (i.e. merge ... or link)
> the
> markup, so it is perfectly legal to use  when there
> is
> a  somewhere, as they won't be related.
> Therefore,
> no of the concerns you mention would apply, as ...
> 
> The concept of abstract/implement is the same as in OOP's inheritance.
> What
> goes in child, is from the subclass! Exclamation mark! ;)*
> 
> Ok, you propose a new attribute for extend/abstract, child/implement pair
> tags. And you say that this id attribute will NOT have any relationship
> with
> wicket:id. Well, isn't this something... scary? The documentation will
> have
> to take care of this, because it will _not_ be intuitive.
> 
> Regards,
> 
> 
> On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
> wrote:
> 
>>
>> Hi Mats, let me try to explain what Chris and I see here that others
>> don't
>> -
>> may it be there or not ;)
>>
>> You can of course do everything with panels that could be done with
>> multiple
>> abstract sections (may they be named wicket:child or wicket:abstract).
>> However, if this is the only argument, you wouldn't need markup
>> inheritance
>> at all! The proposed change is just an extension of exactly this markup
>> inheritance concept (that everybody loves) to make it even more powerful
>> than it already is.
>>
>> I was quite new to wicket (which I still am) and came across a situation
>> where I wanted to use two abstract sections: one for a sub-navigation
>> that
>> was common for several pages in a section and one for the actual content.
>> For me, as a wicket newbie, it would have been most natural to use markup
>> inheritance to solve this problem. Using abstract methods, while being a
>> nice solution (workaround?), didn't come to my mind at once, nor did I
>> find
>> it somewhere in the docs.
>>
>> imho, there are two possible solution to this problem:
>> 1. promote using abstract methods for this in the docs as the wicket-way
>> of
>> doing it
>> 2. extend the current markup inheritance mechanism (which I tried to do
>>

RE: Multiple tags on a single base page?

> page's markup. Wicket is the first framework I've seen that allows
>> > proper OO reuse concepts at the markup level.
>> >
>> > This is what many people wicket developers with an OO wiring in their
>> > brain are doing right now with the existing child/extend feature - and
>> > to great benefit.
>> >
>> > This new feature, or extension of the exiting feature, allows more than
>> > one section of markup to be "specialized" by derived (extended) markups
>> > whereas currently wicket only supports the deferred
>> > definition/implementation of a single markup section in any page. In
>> > other words we want to make a powerful feature even more powerful.
>> >
>> > It must be stated again (for the benefit of those who have just
>> recently
>> > joined this thread) that supporting multiple sections whose
>> > implementation can be deferred to extended markups does not equate to
>> > multiple inheritance (a big "no no" in the OO world). Multiple
>> > overridden sections is analogous to the support of multiple abstract
>> > methods whose implementations are provided in classes that extend the
>> > base class - which is supported in all good OO languages, including
>> > Java.
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>> 
>> 
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context: http://www.nabble.com/Multiple-
>> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
>> tf4738673.html#a13623108
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>> 
>> 
>> -
>> 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]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626128
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: Multiple tags on a single base page?

Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)

You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.

I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.

imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)

-- stefan

Mats Norén-2 wrote:
> 
> On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
>> Hmm...I'm interested in seeing the difference as well. I would love to
>> get it but right now I don't.
>>
>> Chris Colman wrote:
>> "This new feature, or extension of the exiting feature, allows more than
>> one section of markup to be "specialized" by derived (extended) markups
>> whereas currently wicket only supports the deferred
>> definition/implementation of a single markup section in any page. In
>> other words we want to make a powerful feature even more powerful."
>>
>> Is the above statement really true considering that by adding abstract
>> methods to your page you defer the creation of the markup in just the
>> same way as the new proposed solution?
>>
>> BasePage.java
>>
>> public BasePage() {
>> addAbstract1("abstractId1");
>> addAbstract2("abstractId2);
>> }
>>
>> public abstract addAbstract1(String abstractId1);
>> public abstract addAbstract2(String abstractId2);
> 
> A little typo here..I meant:
> 
> public BasePage() {
> add(addAbstract1("abstractId1"));
> add(addAbstract2("abstractId2));
>  }
> 
> public abstract Component addAbstract1(String abstractId1);
> public abstract Component addAbstract2(String abstractId2);
> 
> /Mats
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
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: Multiple tags on a single base page?


Hey Chris, I would need some lobbying here! ;)

-- stefan



Chris Colman wrote:
> 
>> Wouldn't this essentially be the same as using > id="header"/> and using WebMarkupContainers on the java side?
>> I.e.:
>> 
>> Base
>> 
> 
> Structural markup goes here (see below for explanation of this)
> 
>> 
> 
> More structural markup goes here
> 
>> 
> 
> And again more structural markup goes here too
> 
>> 
>> PumpsBase
>> -
>> 
>> A header for all pages to do with pumps
>> 
>> 
>> Note: no body implemented here - deferred until a more specialized
>> class/markups: WaterPumpsBase and OilPumpsBase
>> 
>> WaterPumpBase
>> -
>> Note: no header implemented here - the general PumpsBase one suffices
>> for all pumps pages
>> 
>> 
>> A body discussing water pumps
>> 
>> 
> ...
> 
>> 
>> On the java side you'd have to addOrReplace(new
>> WebMarkupContainer("header")) but it's essentially the same. Or am I
>> missing some point?
> 
> This is indeed very different. If it were not so then the wicket
> developers would never have conceived the need for the current
> child/extend tag pair.
> 
> The power of inheritance at the markup level is that you can define
> markup once in a base markup file that is inherited by all derived
> markup files. The derived markup files only supply sections that provide
> "specialized sections of markup - the rest, at render time, comes from
> the base class.
> 
> You would typically use components (panels) within these specialized
> sections but using the panel mechanism as you describe above as a
> replacement for the powerful markup inheritance feature of wicket is not
> possible.
> 
> In the panel example you give you must still provide all of the
> structural markup surrounding your panel tags in EVERY page's markup in
> your system and if you decide to make a system wide change of this
> structural markup you must edit every page's markup to reflect that
> change. In an OO markup world you provide the structural markup in as
> many pages as you want but at render time the only structural markup
> used is that provided in the base base - which is very powerful because
> you can make system wide changes by modifying only that single base
> page's markup. Wicket is the first framework I've seen that allows
> proper OO reuse concepts at the markup level.
> 
> This is what many people wicket developers with an OO wiring in their
> brain are doing right now with the existing child/extend feature - and
> to great benefit.
> 
> This new feature, or extension of the exiting feature, allows more than
> one section of markup to be "specialized" by derived (extended) markups
> whereas currently wicket only supports the deferred
> definition/implementation of a single markup section in any page. In
> other words we want to make a powerful feature even more powerful. 
> 
> It must be stated again (for the benefit of those who have just recently
> joined this thread) that supporting multiple sections whose
> implementation can be deferred to extended markups does not equate to
> multiple inheritance (a big "no no" in the OO world). Multiple
> overridden sections is analogous to the support of multiple abstract
> methods whose implementations are provided in classes that extend the
> base class - which is supported in all good OO languages, including
> Java.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623108
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: Multiple tags on a single base page?


Well, the tags are not new, as they do the perfectly same as extend and
child. Basically, the patch only introduces an id attribute to those tags in
order to make linking of markup more flexible. The new names were only
introduced to keep functionality of the patch separated from the existing
(and as the names child/extend are not very well chosen, as they aren't
naturally related)

I see that it was a bad idea to rename the tags for the prototype.
Obviously, everybody fears new tags and therefore dismisses the whole idea
only for that reason.



Evan Chooly wrote:
> 
> In our app we have a ListView into which we can dump panels for, in
> our case, various different filtering options depending on the page.
> The base page keeps a List and that's used as the model for the
> ListView.  If the subclass doesn't add anything, nothing shows up.
> But the pages that need them can add them.  These panels show up in
> the base page's markup area (outside the  area) with no
> hackery needed.
> 
> I think the proposed patch is an overly complicated solution to
> "problem" that has many different simple solutions.  I agree with the
> earlier comments about the proliferation of tags in wicket.  I'd
> rather not see new tags added just for this.  It fuglifies the markup
> for no real gain.
> 
> On Nov 6, 2007 11:30 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
> wrote:
>>
>> I posted a new message in Wicket - Dev:
>> http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html
>>
>> It contains a patch that demonstrates the discussed enhancement. Please
>> comment!
>>
>> -- stefan
>>
>>
>> Stefan Fußenegger wrote:
>> >
>> > Hi folks,
>> >
>> > I just stumbled on a situation where it would be useful to have two or
>> > more  tags in a base page. Just consider a layout that
>> > consists of the usual footer, header, navigation, and content parts.
>> But
>> > now, the content should be arranged in two columns, e.g. two different
>> > s.
>> >
>> > To give a short example, the BasePage.html cloud look like this
>> >
>> > 
>> > 
>> >
>> > 
>> >
>> > 
>> > 
>> > 
>> >
>> > 
>> >
>> > 
>> > 
>> > 
>> >
>> > 
>> > 
>> > 
>> >
>> > And the Child.html markup would look like this:
>> >
>> > 
>> > 
>> >
>> > 
>> > 
>> > 
>> > 
>> > 
>> >
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> >
>> > Wouldn't that be a desirable feature? I tried to run the above example
>> > expecting to get an exception. The second wicket:child/wicket:extend
>> pair
>> > was happily ignored though.
>> >
>> > Best regards, Stefan
>> >
>>
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287
>>
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> 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]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623106
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: Make PageableListView row click


add javascript to your  tags

pure html sample:

  
Test
Test
Test
Test
  

(Source:
http://radio.javaranch.com/pascarello/2004/12/30/1104419159000.html)



Marco Aurélio Silva wrote:
> 
> Hi all
> 
> I'm using a PageableListView component and I want to make each row of the
> list clickable. I don't want to add a column with a label like "details",
> I
> just want to click in any place of the row to go to details. Is there a
> way
> to do this?
> 
> Thanks in advance
> Marco
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Make-PageableListView-row-click-tf4759886.html#a13612378
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: Multiple tags on a single base page?


I posted a new message in Wicket - Dev:
http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html

It contains a patch that demonstrates the discussed enhancement. Please
comment!

-- stefan


Stefan Fußenegger wrote:
> 
> Hi folks,
> 
> I just stumbled on a situation where it would be useful to have two or
> more  tags in a base page. Just consider a layout that
> consists of the usual footer, header, navigation, and content parts. But
> now, the content should be arranged in two columns, e.g. two different
> s.
> 
> To give a short example, the BasePage.html cloud look like this
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> And the Child.html markup would look like this:
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
> 
> Wouldn't that be a desirable feature? I tried to run the above example
> expecting to get an exception. The second wicket:child/wicket:extend pair
> was happily ignored though.
> 
> Best regards, Stefan
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287
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: Multiple tags on a single base page?


The proposed extension would just lead to more convenience, as it saves us
from having to create child pages as page/panel pairs when their are 2
panels needed (assuming no inheritance at all)




John Krasnay wrote:
> 
> On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
>> 
>> In the panel example you give you must still provide all of the
>> structural markup surrounding your panel tags in EVERY page's markup in
>> your system and if you decide to make a system wide change of this
>> structural markup you must edit every page's markup to reflect that
>> change. In an OO markup world you provide the structural markup in as
> 
> Huh? Why wouldn't the structural markup be inherited by child pages?
> 
> To my mind, wicket:extend/wicket:child is just a convenience feature, to
> save us from having to create child pages as page/panel pairs.
> 
> jk
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13609607
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: Multiple tags on a single base page?


Don't worry, I won't change the old stuff. I just wanted to say that it would
have been nice to just override some methods of the old class to change its
behaviour. Now, I ended up duplicating most of the old 270-line method into
a bunch of smaller methods for better extensibility.

I won't use child as an alias, as this would probably change too much of the
old implementation. But yes, it is possible to just rename child to abstract
and extend to implement without giving any IDs as null is a valid one (so
using it as an alias would be possible if needed/wanted).

To give a short progress report: I am halfway there ;)



Chris Colman wrote:
> 
>> I totally agree with you, having named extension points would be perfect.
>> However, I am trying to do a quick proof of concept that can be discussed
>> before I implement all those nice and shiny features. Hopefully this
>> prototype convinces some of those sceptics out there ;)
> 
> I think the anyone who understands how Java supports multiple abstract
> methods without supporting multiple inheritance should be convinced. If it
> makes sense for OO languages to support multiple overriddable abstract
> methods why should wicket be limited to only a single overridable markup
> section?
> 
>> I already figured out how to implement this change. Basically, it's only
>> a
>> single method (MergedMarkup.merge(...)) to change ... but this method has
>> 275 lines and needs *major* refactoring ... damn.
> 
> Doh! I reckon you'll have more success adding a completely new tag set
> because touching the old one get people worried that it might break. If
> you have a new tag set you are free to define the syntax and behaviour -
> and you have no chance of breaking how the old tag set works. There's
> nothing wrong with two tag sets - especially as the new one can be named
> correctly and will have to support named extension points, eventually.
>  
>> 
>> However, changing the name of the tag (while it would make perfect sense)
>> seems to be more complicated. You would have to make sure, that tags are
>> not
>> mixed up and decide between two different markup-merging-implementations,
>> although one implementation is capable of doing the same as the other one
>> -
>> and more.
> 
> Maybe make 'child' an alias for 'abstract' and 'extends' an alias for
> 'implements' and then use your funky new markup-merging-implementation to
> handle both multiple (if names are provided) and fallback to single (if no
> names are provided) - single is then just an ordinary case of multiple
> where n=1.
> 
>> 
>> However, I'll consider using a different name and separate implementation
>> for the prototype.
>> 
>> -- Stefan
>> 
>> 
>> 
>> Chris Colman wrote:
>> >
>> >> if i were you i would use tags other then extend and child just so you
>> >> dont conflict.
>> >
>> > Yes Stefan, I would think that would be a better approach to use a new
>> set
>> > of tags. It also allows you to choose more correct naming (because
>> > inheritance isn't actually a parent/child relationship so the word
>> child
>> > just confuses the issue).
>> >
>> > Maybe wicket:abstract in the base and wicket:implements (nice - thanks
>> to
>> > whoever suggested that) or wicket:override in the derived (extended)
>> > markup.
>> >
>> > I think using IDs up front would also be great, if not necessary,
>> because
>> > in Java as would probably occur in wicket mark up, you can have
>> > intermediate classes that don't implement all abstract methods in a
>> base
>> > class. Without IDs you won't know exactly which abstract method an
>> > intermediate class is implementing.
>> >
>> > This example hopefully demonstrates what I mean:
>> >
>> > Base
>> > 
>> > 
>> > 
>> >
>> > PumpsBase
>> > -
>> > 
>> >A header for all pages to do with pumps
>> > 
>> >
>> > Note: no body implemented here - deferred until a more specialized
>> > class/markups: WaterPumpsBase and OilPumpsBase
>> >
>> > WaterPumpBase
>> > -
>> > Note: no header implemented here - the general PumpsBase one suffices
>> for
>> > all pumps pages
>> >
>> > 
>> >A body discussing water pumps
>> > 
>> >
>> >
>> > OilPumpBase
>> > ---
>> > Note: no

Re: Wicket namespace?


Sure, dtd = old way, xsd = new way. But sadly, there is no official XHTML 1.0
Schema to extend (yet). However, there are two candidates for the future:
http://www.w3.org/TR/xhtml1-schema/ (work in progress) and
http://www.w3.org/TR/xhtml-modularization/ (working draft). Hence, the only
way to extend xhtml right now is by means of a DTD.

-- stefan


Will Jackson-2 wrote:
> 
> I know you were not saying that it's not supported. I was assuming that it
> was not supported because I can't find a public url for that supports it
> :) 
> 
> afaik extending the dtd is really just adding another dtd
> (http://www.w3.org/TR/1999/xhtml-modularization-19990406/developing.html#sec_6.5.2.).
>  
> as far as the schema is concerned anything that can be done in a dtd can
> be done in a more elegant manner in an xsd (dtd = old way, xsd = new way).
> still curious why there isn't a public url that is published somewhere on
> it's use :(
> 
> Stefan Fußenegger <[EMAIL PROTECTED]> wrote: 
> I didn't say it's not supported, I was just asking. And I don't think you
> have to use 2 DTDs. I think it rather is an extension of the standard
> XHTML
> DTD (that's why it is a DTD and not an XML schema). 
> 
> -- Stefan
> 
> 
> 
> Will Jackson-2 wrote:
>> 
>> Thanks for the info... hmmm... I wonder why it is not supported? I would
>> have assumed that they would use a xsd rather than a dtd. How would this
>> be used? Using multiple dtds can get messy (not to mention they may cause
>> issues in Internet Exploder).
>> 
>> 
>>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>> 
>> 
>> Better:
>> 
>> 
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xmlns:wicket="http://wicket.apache.org";
>> xsi:schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd
>> http://wicket.apache.org/someWicketSchema";
>> xml:lang="en">
>> 
>> Stefan Fußenegger  wrote: 
>> I was asking myself the same a while ago. Today I found a file named
>> wicket-xhtml1-strict.dtd in the SVN. You can find it at
>> http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
>>  
>> 
>> But I don't know whether this file is supported or not, as I haven't
>> found
>> anything in the docs. Does somebody know more?
>> 
>> Regards, Stefan
>> 
>> 
>> 
>> Frank Bille-2 wrote:
>>> 
>>> There is no schema for it if thats what you mean.
>>> 
>>> But you can set the namespace to wicket:xmlns="http://wicket.apache.org";
>>> 
>>> Frank
>>> 
>>> On Nov 5, 2007 10:42 PM, Will Jackson  wrote:
>>> 
>>>> no one knows what the Wicket namespace is?
>>>>
>>>> Will Jackson  wrote: Is there a Wicket xhtml
>>>> namespace that will work with Eclipse content assist? I searched the
>>>> forums,
>>>> but can't find anything.
>>>>
>>>>  __
>>>> Do You Yahoo!?
>>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>>> http://mail.yahoo.com
>>>>
>>>>  __
>>>> Do You Yahoo!?
>>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>>> http://mail.yahoo.com
>>>>
>>> 
>>> 
>> 
>> 
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> -- 
>> View this message in context:
>> http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
>>  ______
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com 
>> 
> 
> 
> -
> ---
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> -- 
> View this message in context:
> http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597735
> Sent from the Wicket - User mailing list archive at Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
>  __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13602619
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: Wicket namespace?


In deed, it's an open issue: https://issues.apache.org/jira/browse/WICKET-693




Timo Rantalaiho wrote:
> 
> On Mon, 05 Nov 2007, Stefan Fußenegger wrote:
>> I was asking myself the same a while ago. Today I found a file named
>> wicket-xhtml1-strict.dtd in the SVN. You can find it at
>> http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
>>  
>> 
>> But I don't know whether this file is supported or not, as I haven't
>> found
>> anything in the docs. Does somebody know more?
> 
> I just know that I have used it and sometimes it has helped 
> me. I had to add the "wicket:" attributes to my editor (IDEA)
> by quick fix though, but that's just once per project.
> 
> Your mileage may vary.
> 
> I think that there is a Jira issue about this as well 
> ("What to do with the Wicket DTD" or something such), so if
> you have good ideas put them there :)
> 
> Best wishes,
> Timo
> 
> 
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13602399
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: Wicket namespace?


I didn't say it's not supported, I was just asking. And I don't think you
have to use 2 DTDs. I think it rather is an extension of the standard XHTML
DTD (that's why it is a DTD and not an XML schema). 

-- Stefan



Will Jackson-2 wrote:
> 
> Thanks for the info... hmmm... I wonder why it is not supported? I would
> have assumed that they would use a xsd rather than a dtd. How would this
> be used? Using multiple dtds can get messy (not to mention they may cause
> issues in Internet Exploder).
> 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en">
> 
> Better:
> 
> http://www.w3.org/1999/xhtml";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:wicket="http://wicket.apache.org";
> xsi:schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd
> http://wicket.apache.org/someWicketSchema";
> xml:lang="en">
> 
> Stefan Fußenegger <[EMAIL PROTECTED]> wrote: 
> I was asking myself the same a while ago. Today I found a file named
> wicket-xhtml1-strict.dtd in the SVN. You can find it at
> http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
>  
> 
> But I don't know whether this file is supported or not, as I haven't found
> anything in the docs. Does somebody know more?
> 
> Regards, Stefan
> 
> 
> 
> Frank Bille-2 wrote:
>> 
>> There is no schema for it if thats what you mean.
>> 
>> But you can set the namespace to wicket:xmlns="http://wicket.apache.org";
>> 
>> Frank
>> 
>> On Nov 5, 2007 10:42 PM, Will Jackson  wrote:
>> 
>>> no one knows what the Wicket namespace is?
>>>
>>> Will Jackson  wrote: Is there a Wicket xhtml
>>> namespace that will work with Eclipse content assist? I searched the
>>> forums,
>>> but can't find anything.
>>>
>>>  ______
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>>
>>>  __
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>>
>> 
>> 
> 
> 
> -
> ---
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> -- 
> View this message in context:
> http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017
> Sent from the Wicket - User mailing list archive at Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
>  __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597735
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: Multiple tags on a single base page?


I totally agree with you, having named extension points would be perfect.
However, I am trying to do a quick proof of concept that can be discussed
before I implement all those nice and shiny features. Hopefully this
prototype convinces some of those sceptics out there ;)

I already figured out how to implement this change. Basically, it's only a
single method (MergedMarkup.merge(...)) to change ... but this method has
275 lines and needs *major* refactoring ... damn.

However, changing the name of the tag (while it would make perfect sense)
seems to be more complicated. You would have to make sure, that tags are not
mixed up and decide between two different markup-merging-implementations,
although one implementation is capable of doing the same as the other one -
and more.

However, I'll consider using a different name and separate implementation
for the prototype.

-- Stefan



Chris Colman wrote:
> 
>> if i were you i would use tags other then extend and child just so you
>> dont conflict.
> 
> Yes Stefan, I would think that would be a better approach to use a new set
> of tags. It also allows you to choose more correct naming (because
> inheritance isn't actually a parent/child relationship so the word child
> just confuses the issue).
> 
> Maybe wicket:abstract in the base and wicket:implements (nice - thanks to
> whoever suggested that) or wicket:override in the derived (extended)
> markup.
> 
> I think using IDs up front would also be great, if not necessary, because
> in Java as would probably occur in wicket mark up, you can have
> intermediate classes that don't implement all abstract methods in a base
> class. Without IDs you won't know exactly which abstract method an
> intermediate class is implementing.
> 
> This example hopefully demonstrates what I mean:
> 
> Base
> 
> 
> 
> 
> PumpsBase
> -
> 
>   A header for all pages to do with pumps
> 
> 
> Note: no body implemented here - deferred until a more specialized
> class/markups: WaterPumpsBase and OilPumpsBase
> 
> WaterPumpBase
> -
> Note: no header implemented here - the general PumpsBase one suffices for
> all pumps pages
> 
> 
>   A body discussing water pumps
> 
> 
> 
> OilPumpBase
> ---
> Note: no header implemented here - the general PumpsBase one suffices for
> all pumps pages
> 
> 
>   A body discussing oil pumps
> 
> 
> 
> I think the tag pairs abstract/implements flow much better from an OO
> perspective than child/extends. It hurts my brain way to much to think of
> a base class as a child.
> 
>> 
>> -igor
>> 
>> 
>> On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>> >
>> > Well, what I'd like to do is what I explained in my first post. One
>> would
>> > still have a one-one-relationship if it comes to files (Base.html,
>> Base.java
>> > - Sub.html, Sub.java). However, a Base.html might contain more than one
>> > . So this no longer an exact duplicate of the parent-
>> child
>> > relationship that is already specified by the java class hierarchy. It
>> now
>> > would be similar to abstract method, where the abstract class specifies
>> one
>> > or more extension points that are implemented by its subcasses ...
>> abstract
>> > methods. There isn't a restriction, that there is only one abstract
>> method
>> > per class!
>> >
>> > My proof of concept would go the probably easiest way and just link the
>> > first extend with the first child, the second extend with the second
>> child,
>> > the third ... you got the idea ;) At a later point it might be useful
>> to
>> > link them using ids (like the names of abstract methods).
>> >
>> > You could than for instance do some hierarchies like this:
>> >
>> > BaseClass - Application base class. Navigation on top, two columns with
>> > wicket:extend
>> > SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> > sub-navigation in left column and some fancy content in right column
>> >
>> > I totally agree to anybody who argues that this is already possible by
>> other
>> > means. However, to me it seems to be the most natural and elegant way
>> to
>> do
>> > this.
>> >
>> > As I mentioned before, I don't know Wicket's inner workings too much,
>> so
>> I
>> > will definitely need some pointers to the right directio

Re: Wicket namespace?


I was asking myself the same a while ago. Today I found a file named
wicket-xhtml1-strict.dtd in the SVN. You can find it at
http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd
 

But I don't know whether this file is supported or not, as I haven't found
anything in the docs. Does somebody know more?

Regards, Stefan



Frank Bille-2 wrote:
> 
> There is no schema for it if thats what you mean.
> 
> But you can set the namespace to wicket:xmlns="http://wicket.apache.org";
> 
> Frank
> 
> On Nov 5, 2007 10:42 PM, Will Jackson <[EMAIL PROTECTED]> wrote:
> 
>> no one knows what the Wicket namespace is?
>>
>> Will Jackson <[EMAIL PROTECTED]> wrote: Is there a Wicket xhtml
>> namespace that will work with Eclipse content assist? I searched the
>> forums,
>> but can't find anything.
>>
>>  __
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>>  __
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
> 
> 


-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017
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: Multiple tags on a single base page?

but why choose another name? as long as there is only one pair of however
named tags, the behaviour wouldn't change at all. It would only extend the
current functionality for those who place a second extension point in there
html files. 

But I am not in the core team, but curious to look under the hood. While I
would love to see this extension becoming part of wicket, I don't care too
much what happens with it as long as I have fun implementing it. ;)

And as numerous times mentioned before: This extension still aligns with how
class inheritance works in java, you only have to see html files as classes
and extension points as (abstract) methods. That's the only conceptual
change.

But there is still some time left to argue while I am hacking ;) 

Regards

igor.vaynberg wrote:
> 
> On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>>
>> well, i thought chris' suggestion to use abstract and override in order
>> to
>> align it with the java keyword/annotation. I don't care whether it is
>> implement or override (but yes, names are important). i think i'll go for
>> implement though ... but if it finally becomes part of wicket, it will
>> become extend/child anyway, wouldn't it?
> 
> no it would not.
> 
> as mentioned numerous times before, we like how it currently works
> because it aligns with how class inheritance works in java and thus is
> easy to understand.
> 
> this would be an in-addion-to feature that people may choose to use.
> 
> -igor
> 
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13590818
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: Multiple tags on a single base page?


well, i thought chris' suggestion to use abstract and override in order to
align it with the java keyword/annotation. I don't care whether it is
implement or override (but yes, names are important). i think i'll go for
implement though ... but if it finally becomes part of wicket, it will
become extend/child anyway, wouldn't it? but let's see what i can do here
first.



igor.vaynberg wrote:
> 
> the complement to abstract is implement not override... names are
> important.
> 
> -igor
> 
> 
> On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>>
>> thanks for that advise.
>>
>> hey chris, keep your fingers crossed. finally you could get your
>> wicket:abstract-wicket:override ;)
>>
>> stefan
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > if i were you i would use tags other then extend and child just so you
>> > dont conflict.
>> >
>> > -igor
>> >
>> >
>> > On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Well, what I'd like to do is what I explained in my first post. One
>> would
>> >> still have a one-one-relationship if it comes to files (Base.html,
>> >> Base.java
>> >> - Sub.html, Sub.java). However, a Base.html might contain more than
>> one
>> >> . So this no longer an exact duplicate of the
>> >> parent-child
>> >> relationship that is already specified by the java class hierarchy. It
>> >> now
>> >> would be similar to abstract method, where the abstract class
>> specifies
>> >> one
>> >> or more extension points that are implemented by its subcasses ...
>> >> abstract
>> >> methods. There isn't a restriction, that there is only one abstract
>> >> method
>> >> per class!
>> >>
>> >> My proof of concept would go the probably easiest way and just link
>> the
>> >> first extend with the first child, the second extend with the second
>> >> child,
>> >> the third ... you got the idea ;) At a later point it might be useful
>> to
>> >> link them using ids (like the names of abstract methods).
>> >>
>> >> You could than for instance do some hierarchies like this:
>> >>
>> >> BaseClass - Application base class. Navigation on top, two columns
>> with
>> >> wicket:extend
>> >> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> >> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> >> sub-navigation in left column and some fancy content in right column
>> >>
>> >> I totally agree to anybody who argues that this is already possible by
>> >> other
>> >> means. However, to me it seems to be the most natural and elegant way
>> to
>> >> do
>> >> this.
>> >>
>> >> As I mentioned before, I don't know Wicket's inner workings too much,
>> so
>> >> I
>> >> will definitely need some pointers to the right directions.
>> >>
>> >> My naive guess is that Wicket parses BasePage.html and looks for
>> >> SecionOneBaseClass.html and the first  as soon as it
>> >> finds a
>> >> . The idea would know be to just add a counter to
>> this
>> >> call, asking for the second , rather than the first (I
>> >> doubt
>> >> that it's really going to be that easy though).
>> >>
>> >>
>> >>
>> >>
>> >> Bruno Borges wrote:
>> >> >
>> >> > Stefan, try first giving us an example of what would you like to do.
>> >> What
>> >> > I
>> >> > can see is that you want this:
>> >> >
>> >> > BasePage.html
>> >> > 
>> >> >   
>> >> > BasePage
>> >> > 
>> >> > This is my child:
>> >> > 
>> >> > 
>> >> > This is my OTHER child:
>> >> > 
>> >> >   
>> >> > 
>> >> >
>> >> > ** Example of a child page:*
>> >> > ChildPage.html
>> >> > 
>> >> >   
>> >> > 
>> >> >   ChildPage
>> >> >   I'm your child
>> >> > 
>> >> >   
>> >> > 
&g

Re: Multiple tags on a single base page?


thanks for that advise.

hey chris, keep your fingers crossed. finally you could get your
wicket:abstract-wicket:override ;)

stefan



igor.vaynberg wrote:
> 
> if i were you i would use tags other then extend and child just so you
> dont conflict.
> 
> -igor
> 
> 
> On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>>
>> Well, what I'd like to do is what I explained in my first post. One would
>> still have a one-one-relationship if it comes to files (Base.html,
>> Base.java
>> - Sub.html, Sub.java). However, a Base.html might contain more than one
>> . So this no longer an exact duplicate of the
>> parent-child
>> relationship that is already specified by the java class hierarchy. It
>> now
>> would be similar to abstract method, where the abstract class specifies
>> one
>> or more extension points that are implemented by its subcasses ...
>> abstract
>> methods. There isn't a restriction, that there is only one abstract
>> method
>> per class!
>>
>> My proof of concept would go the probably easiest way and just link the
>> first extend with the first child, the second extend with the second
>> child,
>> the third ... you got the idea ;) At a later point it might be useful to
>> link them using ids (like the names of abstract methods).
>>
>> You could than for instance do some hierarchies like this:
>>
>> BaseClass - Application base class. Navigation on top, two columns with
>> wicket:extend
>> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> sub-navigation in left column and some fancy content in right column
>>
>> I totally agree to anybody who argues that this is already possible by
>> other
>> means. However, to me it seems to be the most natural and elegant way to
>> do
>> this.
>>
>> As I mentioned before, I don't know Wicket's inner workings too much, so
>> I
>> will definitely need some pointers to the right directions.
>>
>> My naive guess is that Wicket parses BasePage.html and looks for
>> SecionOneBaseClass.html and the first  as soon as it
>> finds a
>> . The idea would know be to just add a counter to this
>> call, asking for the second , rather than the first (I
>> doubt
>> that it's really going to be that easy though).
>>
>>
>>
>>
>> Bruno Borges wrote:
>> >
>> > Stefan, try first giving us an example of what would you like to do.
>> What
>> > I
>> > can see is that you want this:
>> >
>> > BasePage.html
>> > 
>> >   
>> > BasePage
>> > 
>> > This is my child:
>> > 
>> > 
>> > This is my OTHER child:
>> > 
>> >   
>> > 
>> >
>> > ** Example of a child page:*
>> > ChildPage.html
>> > 
>> >   
>> > 
>> >   ChildPage
>> >   I'm your child
>> > 
>> >   
>> > 
>> >
>> > Now, given this html, how do you see the Java code structured? What's
>> your
>> > vision?
>> >
>> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
>> > wrote:
>> >
>> >>
>> >>
>> >> Eelco Hillenius wrote:
>> >> >
>> >> >> It would be quite feasible to add support for multiple overridden
>> >> >> sections using the above tag names while remaining backwards
>> >> compatible
>> >> >> with existing markup by continuing to support the old
>> 
>> >> >> tags working the way they always have.
>> >> >
>> >> > It's kind of a predictable answer, but the best way to push new
>> ideas
>> >> > forward is to supply us with a patch, so that we can discuss some
>> >> > working code. The current committers don't see much in the idea, but
>> >> > that doesn't mean they wouldn't want to support at least the option
>> of
>> >> > plugging this in. And hey, maybe some working code convinces us :-)
>> >> >
>> >> > Eelco
>> >> >
>> >> >
>> -
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTEC

Re: Multiple tags on a single base page?


Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html, Base.java
- Sub.html, Sub.java). However, a Base.html might contain more than one
. So this no longer an exact duplicate of the parent-child
relationship that is already specified by the java class hierarchy. It now
would be similar to abstract method, where the abstract class specifies one
or more extension points that are implemented by its subcasses ... abstract
methods. There isn't a restriction, that there is only one abstract method
per class!

My proof of concept would go the probably easiest way and just link the
first extend with the first child, the second extend with the second child,
the third ... you got the idea ;) At a later point it might be useful to
link them using ids (like the names of abstract methods).

You could than for instance do some hierarchies like this:

BaseClass - Application base class. Navigation on top, two columns with
wicket:extend
SectionOneBaseClass extends BaseClass - Sub-navigation in left column
SectionOneIndex extends SectionOneBaseClass - Navigation on top,
sub-navigation in left column and some fancy content in right column

I totally agree to anybody who argues that this is already possible by other
means. However, to me it seems to be the most natural and elegant way to do
this.

As I mentioned before, I don't know Wicket's inner workings too much, so I
will definitely need some pointers to the right directions.

My naive guess is that Wicket parses BasePage.html and looks for
SecionOneBaseClass.html and the first  as soon as it finds a
. The idea would know be to just add a counter to this
call, asking for the second , rather than the first (I doubt
that it's really going to be that easy though).




Bruno Borges wrote:
> 
> Stefan, try first giving us an example of what would you like to do. What
> I
> can see is that you want this:
> 
> BasePage.html
> 
>   
> BasePage
> 
> This is my child:
> 
> 
> This is my OTHER child:
> 
>   
> 
> 
> ** Example of a child page:*
> ChildPage.html
> 
>   
> 
>   ChildPage
>   I'm your child
> 
>   
> 
> 
> Now, given this html, how do you see the Java code structured? What's your
> vision?
> 
> On Nov 5, 2007 11:28 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
> wrote:
> 
>>
>>
>> Eelco Hillenius wrote:
>> >
>> >> It would be quite feasible to add support for multiple overridden
>> >> sections using the above tag names while remaining backwards
>> compatible
>> >> with existing markup by continuing to support the old 
>> >> tags working the way they always have.
>> >
>> > It's kind of a predictable answer, but the best way to push new ideas
>> > forward is to supply us with a patch, so that we can discuss some
>> > working code. The current committers don't see much in the idea, but
>> > that doesn't mean they wouldn't want to support at least the option of
>> > plugging this in. And hey, maybe some working code convinces us :-)
>> >
>> > Eelco
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> Hi eelco,
>>
>> I'd love to do a proof of concept here. Admittedly, I don't know wicket's
>> inner workings very well. But if I get some support, I'd try implementing
>> this. I am currently looking through the code, but can't find where the
>> transition between parent and child takes place (in other words: the line
>> of
>> code that recognizes the wicket:extend tag and takes the appropriate
>> action). If somebody could point me to that line I would try to implement
>> this possible new feature ... well, I'll first estimate the time
>> necessary
>> to do so and see if I can afford it ;)
>>
>> Regards
>>
>>
>>
>> -
>> ---
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
>> 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: Multiple tags on a single base page?