Re: Using the WicketTester WITHOUT rendering a response on submit
On Thu, 22 May 2008, nitinkc wrote: > I am trying to achieve something similar. How did you manage to assign the > TestingWebApplication to your WicketTester?? Thanks! WicketTester wicket = new WicketTester(new TestingWebApplication()); wicket.startComponent/Panel/Page(... Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket and inline JavaScript
I can't give you a fix off the top of my head... that being said..
Your designer should forage into usability.
You can style buttons - in a limited fashion and its not consistent across
browser types - its a PITA! Don't do it!
The last thing we need is buttons that don't look like buttons. The reason
most apps (web and non web) use normal form controls is because users
understand them and are familiar because their OS will look the same. In
the same way links should 99% of the time have a blue underline. Instantly
you know what its behaviour is. "Oh this submits a form, Oh this is a link
it will take me to a site"
I know there has been some "make web 2.0 button tutorial" stuff floating
around recently - perhaps they've seen these and want to add some drop
shadows and [EMAIL PROTECTED]
:) but if your design really needs custom form submits to make it
work...rethink the custom form design and make it standard. Form controls
are a solved problem.
In summary - regardless of the technology in use - in my personal view..
from studying this stuff for years custom buttons is a waste of time and
is actually worse for your app from a usability stand point.
Given the right argument I might be swayed in certain circumstances - but
that's the general rule of thumb.
I work very closely with a designer who was initially into making everything
his canvas! Now he understands usability concerns - and also that it
doesn't effect creativity, but actually makes the apps better.
Edvin Syse wrote:
>
> Hi Ned,
>
> thanks for your reply. I agree with your point of view. Today, however,
> we got bitten because the designer wanted to change all buttons by
> hiding them with jquery, and adding an anchor right after it in the
> dom-tree, so he could style them the way he wanted it (not possible with
> buttons he tells me).
>
> You can see his lovely button on this page:
>
> http://sd.tornado.no/domorder/search/query/testdomain
>
> The way he then triggered the submit buttons is with the following
> Jquery code:
>
> $('.btn.submit').click(function(){
> $(this).prev().click();
> });
>
> This works most of the times, but sometimes, when the wicket ajax stuff
> includes references to 'this', the approach doesn't work, and wicket
> tells me that the ajax request was stopped 'because of precondition'.
>
> That's when he started bitching about the Wicket way of inlining
> JavaScript, so I thought I'd be nice to hear some opinions :))
>
> -- Edvin
>
--
View this message in context:
http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17417072.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: Formatting a DatePickerSettings
To answer my own question, what's needed is to override
DatePickerSettings.toScript(...) and specify "%y" where it specifies "%Y".
On Thu, May 22, 2008 at 10:39 AM, nate roe <[EMAIL PROTECTED]> wrote:
>
> Hrm, I think that StyleDateConverter is new to Wicket 1.3, as is the
> forDatePattern method, unfortunately. I guess I can dig around in the
> DatePicker source and see if I can figure it out.
>
> The thing is, the DateTextField is following my format instructions, but
> when you pick a date from the calendar of the DatePicker, it reverts to the
> locale default. specifically i'm trying to reduce the year to two digits.
>
>
> On Thu, May 22, 2008 at 7:25 AM, Beyonder Unknown <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Hi Nate, I think you have to create/override the factor method in
>> DateTextField and set it from there:
>>
>>
>> protected DateTextField newDateTextField(String id, PropertyModel
>> dateFieldModel)
>> {
>> return new DateTextField(id, dateFieldModel, new
>> StyleDateConverter(false)).forDatePattern(id,dateFieldModel, "MM/dd"yy");
>> }
>>
>> Hope this helps!
>>
>> Regards,
>> Wen Tong--
>> The only constant in life is change.
>>
>>
>> - Original Message
>> From: nate roe <[EMAIL PROTECTED]>
>> To: users@wicket.apache.org
>> Sent: Wednesday, May 21, 2008 3:38:00 PM
>> Subject: Formatting a DatePickerSettings
>>
>> I'm using Wicket 1.2, and WicketExtensions 1.2.
>>
>> I have a DateTextField that is formatted with the String, "MM/dd/yy" This
>> field has a corresponding DatePickerSettings, but the DatePickerSettings
>> doesn't follow this format (it adds dates with four-digit years,
>> "MM/dd/".)
>>
>> How can I change this?
>>
>> Thanks,
>> Nate
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
Re: AjaxLink not clickable in IE
maybe there is a div overlaying your anchor
-igor
On Thu, May 22, 2008 at 3:28 PM, Michael Mehrle <[EMAIL PROTECTED]> wrote:
> Nothing happens in the AJAX debug - checked that first thing. It just
> behaves as if the link doesn't exist.
>
> Michael
>
> -Original Message-
> From: richardwilko [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 22, 2008 1:54 AM
> To: users@wicket.apache.org
> Subject: Re: AjaxLink not clickable in IE
>
>
> I have found ie to be rubbish it comes to javascript, any error in any
> file
> can stop all the javascript on the page working. make sure you dont
> have
> other javascript on the page which causes problems.
>
> Also open up the wicket ajax debug window and see you anything happens
> in
> there when you click on the link.
>
>
> richard
>
>
>
> igor.vaynberg wrote:
>>
>> wow. we spoil our users too much when they complain about not getting
>> a response after 3 hours...
>>
>> -igor
>>
>> On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle
> <[EMAIL PROTECTED]>
>> wrote:
>>> Anyone? Or are we only talking generics today? ;-)
>>>
>>> Seriously, could use a 2nd pair of eyes on this one... any input
>>> appreciated.
>>>
>>> -Original Message-
>>> From: Michael Mehrle [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, May 21, 2008 2:31 PM
>>> To: users@wicket.apache.org
>>> Subject: AjaxLink not clickable in IE
>>>
>>> I've got this AjaxLink:
>>>
>>>
>>>
>>> fooLink = new AjaxLink("fooLink") {
>>>
>>>@Override
>>>
>>>public void
>>> onClick(AjaxRequestTarget target) {
>>>
>>>Boolean
>>> selected = (Boolean) fooCheckBox.getModelObject();
>>>
>>>if
>>> (!selected) {
>>>
>>>
>>> fooCheckBox.setModelObject((new Boolean(true)));
>>>
>>>}
>>>
>>>
>>> target.addComponent(fooCheckBox);
>>>
>>>// pop up
>>> the modal
>>>
>>>
>>> showRecurringFooModal(recurringFooModalWindow, target);
>>>
>>>}
>>>
>>>};
>>>
>>>
>>>
>>> >> key="fooLabel" />
>>>
>>>
>>>
>>> Works fine in Safari and Firefox but in IE it's not clickable - looks
>>> like a link but the mouse pointer doesn't change and nothing happens
>>> when clicking. No error message either in IE's JS console or in AJAX.
>>> Any idea what I'm doing wrong here?
>>>
>>>
>>>
>>> Michael
>>>
>>>
>>> -
>>> 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]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/AjaxLink-not-clickable-in-IE-tp17379705p17399591.h
> tml
> 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]
RE: AjaxLink not clickable in IE
Nothing happens in the AJAX debug - checked that first thing. It just
behaves as if the link doesn't exist.
Michael
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 1:54 AM
To: users@wicket.apache.org
Subject: Re: AjaxLink not clickable in IE
I have found ie to be rubbish it comes to javascript, any error in any
file
can stop all the javascript on the page working. make sure you dont
have
other javascript on the page which causes problems.
Also open up the wicket ajax debug window and see you anything happens
in
there when you click on the link.
richard
igor.vaynberg wrote:
>
> wow. we spoil our users too much when they complain about not getting
> a response after 3 hours...
>
> -igor
>
> On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle
<[EMAIL PROTECTED]>
> wrote:
>> Anyone? Or are we only talking generics today? ;-)
>>
>> Seriously, could use a 2nd pair of eyes on this one... any input
>> appreciated.
>>
>> -Original Message-
>> From: Michael Mehrle [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, May 21, 2008 2:31 PM
>> To: users@wicket.apache.org
>> Subject: AjaxLink not clickable in IE
>>
>> I've got this AjaxLink:
>>
>>
>>
>> fooLink = new AjaxLink("fooLink") {
>>
>>@Override
>>
>>public void
>> onClick(AjaxRequestTarget target) {
>>
>>Boolean
>> selected = (Boolean) fooCheckBox.getModelObject();
>>
>>if
>> (!selected) {
>>
>>
>> fooCheckBox.setModelObject((new Boolean(true)));
>>
>>}
>>
>>
>> target.addComponent(fooCheckBox);
>>
>>// pop up
>> the modal
>>
>>
>> showRecurringFooModal(recurringFooModalWindow, target);
>>
>>}
>>
>>};
>>
>>
>>
>> > key="fooLabel" />
>>
>>
>>
>> Works fine in Safari and Firefox but in IE it's not clickable - looks
>> like a link but the mouse pointer doesn't change and nothing happens
>> when clicking. No error message either in IE's JS console or in AJAX.
>> Any idea what I'm doing wrong here?
>>
>>
>>
>> Michael
>>
>>
>> -
>> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/AjaxLink-not-clickable-in-IE-tp17379705p17399591.h
tml
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]
RE: AjaxLink not clickable in IE
LOL - sorry - I saw tons of messages regarding generics and wanted to
make sure it didn't fall through the cracks.
Yes, you spoil us! :-P
M.
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 6:50 PM
To: users@wicket.apache.org
Subject: Re: AjaxLink not clickable in IE
wow. we spoil our users too much when they complain about not getting
a response after 3 hours...
-igor
On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:
> Anyone? Or are we only talking generics today? ;-)
>
> Seriously, could use a 2nd pair of eyes on this one... any input
> appreciated.
>
> -Original Message-
> From: Michael Mehrle [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 21, 2008 2:31 PM
> To: users@wicket.apache.org
> Subject: AjaxLink not clickable in IE
>
> I've got this AjaxLink:
>
>
>
> fooLink = new AjaxLink("fooLink") {
>
>@Override
>
>public void
> onClick(AjaxRequestTarget target) {
>
>Boolean
> selected = (Boolean) fooCheckBox.getModelObject();
>
>if
> (!selected) {
>
>
> fooCheckBox.setModelObject((new Boolean(true)));
>
>}
>
>
> target.addComponent(fooCheckBox);
>
>// pop up
> the modal
>
>
> showRecurringFooModal(recurringFooModalWindow, target);
>
>}
>
>};
>
>
>
> key="fooLabel" />
>
>
>
> Works fine in Safari and Firefox but in IE it's not clickable - looks
> like a link but the mouse pointer doesn't change and nothing happens
> when clicking. No error message either in IE's JS console or in AJAX.
> Any idea what I'm doing wrong here?
>
>
>
> Michael
>
>
> -
> 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]
missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
Short version of my question:
Why wouldn't redrawing a surrounding span for an AjaxCheckBox (all
embedded inside a ListView) be enough to get it to check its
underlying PropertyModel, and then reflect that new value?
(and is it broken for an underlying PropertyModel's hashmap to return
null for that key?)
Background:
So I'm tearing my hair out over this, because I've (somewhat) deeply
researched what's going on our code side, but might be dumbly missing
something basic on the Wicket side.
We have a list view that iterates over manufacturers, and each
manufacturer has a "pallet control" of devices
(two list boxes w/ move selection to right list, move selection to
left list buttons between) along with a "all for manufacturer"
checkbox
(the checkbox is a bit tricky, because it's also saying "this is true
for this manufacturer even if it's not a device we recognize")
When you click the select all checkbox, it calls the function that
moves everything into the right hand select list, great.
What I'd like to have happen is moving an item from the right hand
list back to the left also unchecks the select box.
I cannot get this checkbox to update for anything!
Another developer has the underlying model contain a
HashMap of manufacturers, so the code is like
final AjaxCheckBox selectAllCheckbox = new
AjaxCheckBox("manufacturerCheckbox", new
PropertyModel(mTargetModel.getManufacturersAsMap(), manufacturerName))
{
then, when the "remove from right list" button is hit, it removes the
manufacturer value from the list (originally it just set it to false;
is it ok to have the Property return "null" for a checkbox value, to
mean false?) and then adds the checkbox to the AjaxRequestTarget ;
actually it adds a containing span, which also (for now) has a label
w/ a timestamp, so I can see that the whole span containing the
checkbox is being redrawn.
I also updated the Target Model's getManufacturersAsMap() function, so
that it logs when it's called. Oddly (to me, again I might be missing
something here) the getManufacturersAsMap() is called when the page is
constructed and when the checkbox is clicked but NOT when the span
including the checkbox is being redrawn.
Just out of curiosity I've tried this with and without the ListView
setReuseItems set to true. I've made sure that appropriate
setOutputMarkupIds are set (it seems some of the rules for making sure
your nesting wicket:id hierarchy are relaxed in the case of ListViews,
though of course I try to be as faithful as always, still that doesn't
seem to be the problem)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: filter for data in security layer
I am not sure i follow you.
According to the log the user does not have the datapermission for the dropdown.
> I tried to set the permissions like in the explanation below, but that didn't
> work:
>
> // Welcome page
> permission ${ComponentPermission} "${front}.Welcome", "inherit, render,
> global";
> permission ${ComponentPermission} "${front}.Welcome", "enable, global";
What is not working?
In general adding custom actions to your pages is only useful if the
page has a securitycheck that actually checks for those actions. In
the case of a welcome page that is probably overkill but for a page
showing for example customer info it would be very useful to check if
the user has global permissions and thus can see any user or local
permissions and this only is the customer is affiliated with one of
his locations. Such a check could be implemented like this.
public boolean isActionAuthorized(WaspAction action)
{
WaspAction combined = null;
WaspAction additional;
ActionFactory factory = getActionFactory();
additional = factory.getAction(Global.class);
combined = action.add(additional);
//wrapped is another isecuritycheck like a component- or
classsecuritycheck
if (wrapped.isActionAuthorized(combined))
return true; //global so everything is allowed
additional = factory.getAction(Location.class);
combined = action.add(additional);
if (wrapped.isActionAuthorized(combined))
return
verifyCustomerLocationMatchesUserLocations(someCustomer, theUser);
return false;
}
The custom security check in the examples simply overrides an existing
check where this check could extend AbstractSecurityCheck but the
principal is the same. You need to check your custom actions yourself.
Not sure if that at all answers your question.
Maurice
>
> Debug logging:
> 2008-05-22 14:47:57,515 DEBUG
> org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) -
> Adding
> org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
> "xxx.yyy.zzz.front.Welcome" "access, render, enable, location, global" to
> everybody
> 2008-05-22 14:47:57,515 DEBUG
> org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) -
> Adding
> org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
> "xxx.yyy.zzz.front.Welcome" "access, inherit, render, location, global" to
> everybody
>
> 2008-05-22 14:48:13,046 DEBUG
> org.apache.wicket.Component.render(Component.java:2284) - Begin render
> [MarkupContainer [Component id = selectLocation, page =
> xxx.yyy.zzz.front.Welcome, path =
> 1:formLocation:selectLocation.DropDownChoice, isVisible = true, isVersioned =
> false]]
> 2008-05-22 14:48:13,046 DEBUG
> org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:224) -
> Subjects[HashKey: -1185945692, sortOrder 0 = [EMAIL PROTECTED] [mailto:[EMAIL
> PROTECTED] does not have or implies
> org.apache.wicket.security.hive.authorization.permissions.DataPermission
> "LocationListModel" "global"
>
> Andrea
>
> -
> On Sun, May 18, 2008 at 7:26 PM, Igor Vaynberg <[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]> wrote:
>> something like this should probably be filter inside the database not
>> by some external filter which forces you to load the entire dataset.
>
> No that would be foolish, but that wasn't suggested.
>
>>
>> -igor
>>
>> On Sun, May 18, 2008 at 9:39 AM, Andrea Jahn <[EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> in our application locations are administered. A user has only rights on
>>> some of the locations, e.g. Munich, Berlin. He should be able to select one
>>> of the allowed locations in a selection box. Then on the different pages
>>> all data are depending on the actually selected location. For example a
>>> DataView shows only the items, which belong to this location.
>>>
>>> Could Swarm support data filtering ?
>
> Yes, especially in 1.3.1 this is a bit cleaner dependency wise. But
> there is no out of the box solution as there are lots of framework
> combinations possible. So get ready for some heavy duty programming :)
>
>>>
>>> I found the following related message.
>>>
>>> http://markmail.org/message/hb42u5xj7xlvumm7
>>> [http://markmail.org/message/hb42u5xj7xlvumm7]
>>> [http://markmail.org/message/hb42u5xj7xlvumm7] (subsection4)
>>>
>>> I like the idea, that the dataproviders get some filters (only the data
>>> which are needed should be read from the database), but where should I
>>> store the filters for the actual selected location in the security layer ?
>>>
>>> Perhaps does someone know examples for that issue (using Wicket, Spring and
>>> Hibernate) ?
>
> Not aware of any examples out there, but here is what we did,
> customiz
Re: refreshingview with textfield items that use validatior
if you use reuseifmodelequalsstrategy then you need to implement equals/hashcode on the models you give to refreshingview -igor On Thu, May 22, 2008 at 11:40 AM, i ii <[EMAIL PROTECTED]> wrote: > > i cannot get to work :( > >> From: [EMAIL PROTECTED] >> To: users@wicket.apache.org >> Subject: RE: refreshingview with textfield items that use validatior >> Date: Thu, 22 May 2008 15:47:52 + >> >> >> thank you for help, but all i find is >> org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and >> org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, >> need to implement org.apache.wicket.markup.repeater.IItemReuseStrategy? >> >> > Date: Thu, 22 May 2008 08:22:41 -0700 >> > From: [EMAIL PROTECTED] >> > To: users@wicket.apache.org >> > Subject: Re: refreshingview with textfield items that use validatior >> > >> > see setitemreusestrategy, there is also an example in >> > wicketstuff.org/wicket13/repeater >> > >> > -igor >> > >> > >> > On Thu, May 22, 2008 at 5:43 AM, i ii <[EMAIL PROTECTED]> wrote: >> > > >> > > how can use refreshingview with textfield items that use validatior? >> > > when i use and validator fails all textfield values reset. i want reset >> > > every request, but not when validator fails. >> > > - >> > > 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]
RE: refreshingview with textfield items that use validatior
i cannot get to work :( > From: [EMAIL PROTECTED] > To: users@wicket.apache.org > Subject: RE: refreshingview with textfield items that use validatior > Date: Thu, 22 May 2008 15:47:52 + > > > thank you for help, but all i find is > org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and > org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, > need to implement org.apache.wicket.markup.repeater.IItemReuseStrategy? > > > Date: Thu, 22 May 2008 08:22:41 -0700 > > From: [EMAIL PROTECTED] > > To: users@wicket.apache.org > > Subject: Re: refreshingview with textfield items that use validatior > > > > see setitemreusestrategy, there is also an example in > > wicketstuff.org/wicket13/repeater > > > > -igor > > > > > > On Thu, May 22, 2008 at 5:43 AM, i ii <[EMAIL PROTECTED]> wrote: > > > > > > how can use refreshingview with textfield items that use validatior? when > > > i use and validator fails all textfield values reset. i want reset every > > > request, but not when validator fails. > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Formatting a DatePickerSettings
Hrm, I think that StyleDateConverter is new to Wicket 1.3, as is the
forDatePattern method, unfortunately. I guess I can dig around in the
DatePicker source and see if I can figure it out.
The thing is, the DateTextField is following my format instructions, but
when you pick a date from the calendar of the DatePicker, it reverts to the
locale default. specifically i'm trying to reduce the year to two digits.
On Thu, May 22, 2008 at 7:25 AM, Beyonder Unknown <[EMAIL PROTECTED]>
wrote:
>
> Hi Nate, I think you have to create/override the factor method in
> DateTextField and set it from there:
>
>
> protected DateTextField newDateTextField(String id, PropertyModel
> dateFieldModel)
> {
> return new DateTextField(id, dateFieldModel, new
> StyleDateConverter(false)).forDatePattern(id,dateFieldModel, "MM/dd"yy");
> }
>
> Hope this helps!
>
> Regards,
> Wen Tong--
> The only constant in life is change.
>
>
> - Original Message
> From: nate roe <[EMAIL PROTECTED]>
> To: users@wicket.apache.org
> Sent: Wednesday, May 21, 2008 3:38:00 PM
> Subject: Formatting a DatePickerSettings
>
> I'm using Wicket 1.2, and WicketExtensions 1.2.
>
> I have a DateTextField that is formatted with the String, "MM/dd/yy" This
> field has a corresponding DatePickerSettings, but the DatePickerSettings
> doesn't follow this format (it adds dates with four-digit years,
> "MM/dd/".)
>
> How can I change this?
>
> Thanks,
> Nate
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Data Access Design for Pagination
you should be performing the query inside iterator() and size() methods. that way you only retrieve the data you are going to display. -igor On Thu, May 22, 2008 at 6:51 AM, wfroud <[EMAIL PROTECTED]> wrote: > > Hi, > > I've been using the DefaultDataTable component in Wicket which allow me to > paginate through a few pages worth of multi column data. > > I believe the general approach is to load all data from the database into > the session first (as a List of Domain Objects ?), then as navigation links > are clicked show subsets of this list? > > I'm using Spring Beans Injection to inject the Data Access Object into a > subclass of SortableDataProvider (called QueryDataProvider). > > Then within the QueryDataProviders constructor I'm calling a method in the > DataAccessObject to create the List of Data Objects. > > The DataProvider's iterator method then calls a subset of the List stored in > the DataAccessObject. > > I'm pretty sure this is an awful way of designing my data access, if I click > the nav links just a bit too fast I get the following error: > > WicketMessage: After 1 minute the Pagemap null is still locked by: > Thread[http-8080-1,5,main], giving up trying to get the page for path: > 16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink > > How should I be doing things differently? > > Thanks for any help, much appreciated. > > Will > -- > View this message in context: > http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.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]
Re: [PROPOSAL] wicketstuff SVN reorganization...
Please keep these types of discussion on the dev@ list. It is hardly a user question (perhaps the confusing bit) So if you go for a vote, do it on dev@ Martijn PS. My boss would *love* you... my desk is a huge pile of paper, cables, cd's, used mugs and cans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] wicketstuff SVN reorganization...
> p.s. Sorry to be such a stickler, but I'm one of those folks who has > to have order. I can't work until I clean my desk up first! :) Haha. You must be popular with girls (at least the ones I know would love a guy like that)! ;-) +1 for doing a vote. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't see progress in progressBar from Safari
I ran into the same problem: http://www.nabble.com/UploadProgress-in-1.3.3---does-it-work--to17372890.html Martijn On Thu, May 22, 2008 at 6:11 PM, Steamus <[EMAIL PROTECTED]> wrote: > > I use standard Wicket ajax progress bar. The Wicket version is 1.3.3. > It works excellent with IE6/7, Fox, Opera (little conflict with Date > picker), but doesn't work with Safari (3.1.1). I can see title 'upload > starting…' only. No bar from left to right, no percentage... > > I checked the example > (http://www.wicket-library.com/wicket-examples/upload/single). It does not > work with Safari too… :-( > > Anybody won this problem? > > -- > View this message in context: > http://www.nabble.com/Can%27t-see-progress-in-progressBar-from-Safari-tp17407714p17407714.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] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Since I like to have the last word in all discussions, let's close this one down and move it to our development list. I have started a [discuss] thread over there with an outline of a process. See you there! Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can't see progress in progressBar from Safari
I use standard Wicket ajax progress bar. The Wicket version is 1.3.3. It works excellent with IE6/7, Fox, Opera (little conflict with Date picker), but doesn’t work with Safari (3.1.1). I can see title ‘upload starting…’ only. No bar from left to right, no percentage... I checked the example (http://www.wicket-library.com/wicket-examples/upload/single). It does not work with Safari too… :-( Anybody won this problem? -- View this message in context: http://www.nabble.com/Can%27t-see-progress-in-progressBar-from-Safari-tp17407714p17407714.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: unit testing setRenderResponse(new Page()) without instantiation of Page
Seems like bookmarkable setResponsePage will not work either. Check:
http://www.nabble.com/How-to-test-setResponsePage-td16802302.html
nitinkc wrote:
>
> I am not sure, but would rather not. I believe this is a standard way to
> create pages in Wicket(passing required arguments in constructors) and
> there should be a mechanism to test this.
>
> On a side note, when I change my code to:
> form.add(new AjaxSubmitLink("submitLink"){
> private static final long serialVersionUID =
> 3239568065916265026L;
>
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form
> form){
> //setResponsePage(new ScheduleEvent(event,
> resources));
> setResponsePage(ScheduleEvent.class);
> }
> });
>
> the following fails
>
> tester.clickLink("eventDetailsGroupBox:eventDetailsForm:submitLink",
> false);
> tester.assertRenderedPage(ScheduleEvent.class);
>
> junit.framework.AssertionFailedError: expected: but
> was:
> at
> org.apache.wicket.util.tester.WicketTester.assertResult(WicketTester.java:575)
> at
> org.apache.wicket.util.tester.WicketTester.assertRenderedPage(WicketTester.java:522)
> at
>
>
>
> I have verified that
> onSubmit(AjaxRequestTarget target, Form form)
> is infact getting called. Any ideas?
>
>
> jwcarman wrote:
>>
>> Can those arguments be put into PageParameters?
>>
>> On Thu, May 22, 2008 at 11:24 AM, nitinkc <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> That won't work for me b'cos I am also passing constructor arguments to
>>> the
>>> response Page.
>>> So "new Page()" is actually "new Page(x,y)".
>>>
>>>
>>> jwcarman wrote:
You could use the bookmarkable version of setResponsePage(). That
just says what type of page to instantiate.
On Thu, May 22, 2008 at 10:51 AM, nitinkc <[EMAIL PROTECTED]>
wrote:
>
> I am looking to unit test the following:
>
>form.add(new AjaxSubmitLink("submitLink"){
>private static final long serialVersionUID =
> 3239568065916265026L;
>
>@Override
>protected void onSubmit(AjaxRequestTarget
> target,
> Form form){
>setResponsePage(new
> ScheduleEvent(event,
> resources));
>}
>
> Calling
> tester.clickLink("submitLink", true);
>
> instantiates the ScheduleEvent class. I want to avoid this as it
> forces
> me
> to mock appropriate parameters for ScheduleEvent. All I want to do is
> check
> that the rendered page is of type ScheduleEvent. ScheduleEvent class
> will
> have it's own unit tests where I want to address issues concerning it.
> Has
> anyone done this??
> --
> View this message in context:
> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17407666.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: Using the WicketTester WITHOUT rendering a response on submit
Timo,
I am trying to achieve something similar. How did you manage to assign the
TestingWebApplication to your WicketTester?? Thanks!
mclev wrote:
>
>
>
> mclev wrote:
>>
>> 4. Can I test that the response page is what I expect when when I first
>> render and when i submit my form
>>
>> So, call me crazy, but it occurs to me that it would be nice if I could
>> "unit test" just my page, verifying that when the code in my page
>> finishes executing everything is what I expect. I don't really care if
>> the response page renders properly (I'll test that in a unit test for
>> that page), I just want to know that the logic in my page in sending off
>> to the new page.
>>
>>
>
> So I figured out a way to do this by extending the
> WebRequestCycleProcessor.respond methods. :
>
> public class TestingWebRequestCycleProcessor extends
> WebRequestCycleProcessor {
>
> private boolean respondingSuspended = false;
>
> public TestingWebRequestCycleProcessor(){
> super();
> }
>
> public boolean isRespondingSuspended() {
> return respondingSuspended;
> }
>
> public void setRespondingSuspended(boolean respondingSuspended) {
> this.respondingSuspended = respondingSuspended;
> }
>
> @Override
> public void respond(RequestCycle requestCycle)
> {
> if (isRespondingSuspended()){
> return;
> }
>
> super.respond(requestCycle);
> }
>
> @Override
> public void respond(RuntimeException e, RequestCycle requestCycle)
> {
> if (isRespondingSuspended()){
> return;
> }
>
> super.respond(e, requestCycle);
> }
> }
>
> then overriding the WicketTester.DummyApplication:
>
> public class TestingWebApplication extends
> WicketTester.DummyWebApplication{
>
> private TestingWebRequestCycleProcessor requestProcessor;
>
> @Override
> protected IRequestCycleProcessor newRequestCycleProcessor()
> {
> requestProcessor = new TestingWebRequestCycleProcessor();
> return requestProcessor;
> }
>
> public void suspendResponding(){
> requestProcessor.setRespondingSuspended(true);
> }
>
> public void unsuspendResponding(){
> requestProcessor.setRespondingSuspended(false);
> }
> }
>
>
> now my test looks like this:
>
> @Test
> public void testSubmitExistingPart(){
> // setup for modifying a part (part has an id -- found by dao)
> setUp();
> final Part part = new MockPart(10);
> final PartDAO mockDAO = module.getmock();
> mockery.checking(new Expectations(){{
> one(mockDAO).findPart(part.getId());
> will(returnValue(part));
> one(mockDAO).save(with(same(part)));
> }});
> PageParameters params = new PageParameters("id="+ part.getId());
> Page page = new PartDetailPage(params);
> tester.startPage(page);
>
> // simulate entry of part data
> FormTester formTester = tester.newFormTester("inputForm");
> String barcode = "123";
> String name = "ABC";
> String description = "XYZ";
> enterFormData(formTester, barcode, name, description);
>
> testApp.suspendResponding(); // so response won't be rendered
> formTester.submit();
>
> // verify values set properly in model;
> assertModelUpdated(part, barcode, name, description);
>
> // verify that response page is correct
> // this now works -- even though the page isn't really
> renderd
> tester.assertRenderedPage(PartListPage.class);
> }
>
> I'm still new to wicket so if anybody thinks this is this is crazy please
> let me know.
>
>
>
--
View this message in context:
http://www.nabble.com/Using-the-WicketTester-WITHOUT-rendering-a-response-on-submit-tp13737447p17407457.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: (Class>) casting troubles
Hi Doug, > The bottom line was that the work didn't take that long and in the end I > feel my code is more readable and type-safe. I have tried 4 times to convert my 1.3 codebase to 1.4 - and failed 4 times. All in all I spent 3 days and just reverted it. There are "API changes" thru generics, which just break the way my app works. Trying to code tables with PropertyColumns and IColumns just isn't readable any more due to having to cast (which before wasn't necessary)... And the many aren't making it any better of course! Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: refreshingview with textfield items that use validatior
thank you for help, but all i find is org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, need to implement org.apache.wicket.markup.repeater.IItemReuseStrategy? > Date: Thu, 22 May 2008 08:22:41 -0700 > From: [EMAIL PROTECTED] > To: users@wicket.apache.org > Subject: Re: refreshingview with textfield items that use validatior > > see setitemreusestrategy, there is also an example in > wicketstuff.org/wicket13/repeater > > -igor > > > On Thu, May 22, 2008 at 5:43 AM, i ii <[EMAIL PROTECTED]> wrote: > > > > how can use refreshingview with textfield items that use validatior? when i > > use and validator fails all textfield values reset. i want reset every > > request, but not when validator fails. > > - > > 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] >
Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.
The following statement
if (!component.isAuto() && getFlag(FLAG_RENDERING))
in Component-> checkHierarchyChange()
returns false when a Behavior is added to the Component.onBeforeRender()
phase, but returns true if
a Behavior is added by another Behavior as part of it's beforeRender()
phase.
So
new Component () {
onBeforeRender() {
add(some behavior);
}
Works.
but
new Component().add(new AbstractBehavior() {
beforeRender(Component c) {
c.addBehavior(some behavior);
}
}
doesn't work, as the getFlag(FLAG_RENDERING) returns false in the first case
and true in the next case.
So in the second case, I get an Exception.
Is this an expected behavior or a possible bug ?
--
View this message in context:
http://www.nabble.com/Possible-BUG---discrepancy-in-component.onBeforeRender-and-IBehavior.beforeRender.-tp17407123p17407123.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: unit testing setRenderResponse(new Page()) without instantiation of Page
I am not sure, but would rather not. I believe this is a standard way to
create pages in Wicket(passing required arguments in constructors) and there
should be a mechanism to test this.
On a side note, when I change my code to:
form.add(new AjaxSubmitLink("submitLink"){
private static final long serialVersionUID =
3239568065916265026L;
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form){
//setResponsePage(new ScheduleEvent(event,
resources));
setResponsePage(ScheduleEvent.class);
}
});
the following fails
tester.clickLink("eventDetailsGroupBox:eventDetailsForm:submitLink",
false);
tester.assertRenderedPage(ScheduleEvent.class);
junit.framework.AssertionFailedError: expected: but
was:
at
org.apache.wicket.util.tester.WicketTester.assertResult(WicketTester.java:575)
at
org.apache.wicket.util.tester.WicketTester.assertRenderedPage(WicketTester.java:522)
at
I have verified that
onSubmit(AjaxRequestTarget target, Form form)
is infact getting called. Any ideas?
jwcarman wrote:
>
> Can those arguments be put into PageParameters?
>
> On Thu, May 22, 2008 at 11:24 AM, nitinkc <[EMAIL PROTECTED]> wrote:
>>
>> That won't work for me b'cos I am also passing constructor arguments to
>> the
>> response Page.
>> So "new Page()" is actually "new Page(x,y)".
>>
>>
>> jwcarman wrote:
>>>
>>> You could use the bookmarkable version of setResponsePage(). That
>>> just says what type of page to instantiate.
>>>
>>>
>>> On Thu, May 22, 2008 at 10:51 AM, nitinkc <[EMAIL PROTECTED]>
>>> wrote:
I am looking to unit test the following:
form.add(new AjaxSubmitLink("submitLink"){
private static final long serialVersionUID =
3239568065916265026L;
@Override
protected void onSubmit(AjaxRequestTarget
target,
Form form){
setResponsePage(new ScheduleEvent(event,
resources));
}
Calling
tester.clickLink("submitLink", true);
instantiates the ScheduleEvent class. I want to avoid this as it forces
me
to mock appropriate parameters for ScheduleEvent. All I want to do is
check
that the rendered page is of type ScheduleEvent. ScheduleEvent class
will
have it's own unit tests where I want to address issues concerning it.
Has
anyone done this??
--
View this message in context:
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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]
>
>
>
--
View this message in context:
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17407117.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]
Focus not getting set after an ajax call
I have an issue with DropDownChoice components with an attached AjaxFormComponentUpdatingBehavior. After the ajax is processed the focus doesn't properly get reset so when the user tabs, the focus jumps back to the top of the page. It doesn't happen all the time, but most of the time (the issue seems somewhat inconsistent and seems to happen more frequently for different fields). When the problem occurs, the ajax debug outputs "last focus id was not set". So apparently, for some reason, the focus id is not set on the ajax call, so it can't be reset properly after the call completes. Any reason why this is occurring and how to fix it? I was originally using wicket 1.3.1, but tried upgrading to 1.3.3, but this did not fix the issue. Thanks. Joel -- View this message in context: http://www.nabble.com/Focus-not-getting-set-after-an-ajax-call-tp17407105p17407105.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: (Class>) casting troubles
actually, if implemented properly EditPage should take IModel
and not Person itself. so unless you typed Link you have IModel
that you have to cast to IModel
-igor
On Thu, May 22, 2008 at 2:45 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote:
>
> Hi Johan,
>
>> I thing that the example below is exactly the thing that generics are
>> pretty
>> good:
>>
>> populateItem(ListItem item) {
>> add(new Link("edit", item.getModel()) {
>> public void onClick() {
>> setResponsePage(new EditPage(getModelObject()));
>> }
>> });
>>
>> (and EditPage is by itself already generified to )
>
> well, just that the Link is IMHO redundant and unnecessary(just
> dropped a note to Martijn, but since you brought that up...)
>
> populateItem(final ListItem item) {
>item.add(new Link("edit") {
>public void onClick() {
>setResponsePage(new EditPage(item.getModelObject()));
>}
>});
>
> So, it might have sense with ListItem, but not necissarily with Link...
>
> Regards, --- Jan.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: unit testing setRenderResponse(new Page()) without instantiation of Page
Can those arguments be put into PageParameters?
On Thu, May 22, 2008 at 11:24 AM, nitinkc <[EMAIL PROTECTED]> wrote:
>
> That won't work for me b'cos I am also passing constructor arguments to the
> response Page.
> So "new Page()" is actually "new Page(x,y)".
>
>
> jwcarman wrote:
>>
>> You could use the bookmarkable version of setResponsePage(). That
>> just says what type of page to instantiate.
>>
>>
>> On Thu, May 22, 2008 at 10:51 AM, nitinkc <[EMAIL PROTECTED]> wrote:
>>>
>>> I am looking to unit test the following:
>>>
>>>form.add(new AjaxSubmitLink("submitLink"){
>>>private static final long serialVersionUID =
>>> 3239568065916265026L;
>>>
>>>@Override
>>>protected void onSubmit(AjaxRequestTarget target,
>>> Form form){
>>>setResponsePage(new ScheduleEvent(event,
>>> resources));
>>>}
>>>
>>> Calling
>>> tester.clickLink("submitLink", true);
>>>
>>> instantiates the ScheduleEvent class. I want to avoid this as it forces
>>> me
>>> to mock appropriate parameters for ScheduleEvent. All I want to do is
>>> check
>>> that the rendered page is of type ScheduleEvent. ScheduleEvent class will
>>> have it's own unit tests where I want to address issues concerning it.
>>> Has
>>> anyone done this??
>>> --
>>> View this message in context:
>>> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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]
Re: unit testing setRenderResponse(new Page()) without instantiation of Page
That won't work for me b'cos I am also passing constructor arguments to the
response Page.
So "new Page()" is actually "new Page(x,y)".
jwcarman wrote:
>
> You could use the bookmarkable version of setResponsePage(). That
> just says what type of page to instantiate.
>
>
> On Thu, May 22, 2008 at 10:51 AM, nitinkc <[EMAIL PROTECTED]> wrote:
>>
>> I am looking to unit test the following:
>>
>>form.add(new AjaxSubmitLink("submitLink"){
>>private static final long serialVersionUID =
>> 3239568065916265026L;
>>
>>@Override
>>protected void onSubmit(AjaxRequestTarget target,
>> Form form){
>>setResponsePage(new ScheduleEvent(event,
>> resources));
>>}
>>
>> Calling
>> tester.clickLink("submitLink", true);
>>
>> instantiates the ScheduleEvent class. I want to avoid this as it forces
>> me
>> to mock appropriate parameters for ScheduleEvent. All I want to do is
>> check
>> that the rendered page is of type ScheduleEvent. ScheduleEvent class will
>> have it's own unit tests where I want to address issues concerning it.
>> Has
>> anyone done this??
>> --
>> View this message in context:
>> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
>
>
>
--
View this message in context:
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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: refreshingview with textfield items that use validatior
see setitemreusestrategy, there is also an example in wicketstuff.org/wicket13/repeater -igor On Thu, May 22, 2008 at 5:43 AM, i ii <[EMAIL PROTECTED]> wrote: > > how can use refreshingview with textfield items that use validatior? when i > use and validator fails all textfield values reset. i want reset every > request, but not when validator fails. > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
I'll chime in again. I really like generics. When I first upgraded to 1.4,
I did a bit of grumbling, but I came to realize some great benefits,
especially with components. I'd hate to lose that (almost as much as I'd
hate to go through my whole code base and remove that work).
I did a couple of things that made things easier. First, all my pages
subclassed from a common ancestor which I just changed to 'extends
WebPage'. Second, I created some utility classes such as
VoidContainer extends WebMarkupContainer
StringLabel extends Label
and so on. I don't feel that having to create these utility classes is a
hassle or is a mark against the API. Rather, it helps me understand how and
where I use certain types of components. It also helps with refactoring.
There is one place that it is ugly, but it is an edge case in a logout link.
I just used @SuppressWarnings to deal with it.
@SuppressWarnings({"unchecked"})
@Override
public void onClick()
{
getSession().invalidate();
// need to use "class" so page is created new
setResponsePage((Class>)
getPage().getClass()));
}
The bottom line was that the work didn't take that long and in the end I
feel my code is more readable and type-safe.
-Doug
Jeremy Thomerson-5 wrote:
>
> I haven't said anything up to this point, but we really don't seem to be
> getting anywhere with what is turning into a religious war. I, for one,
> have already started using 1.4, and love the generics, despite the extra
> verbosity. It gives me extra type safety and code self-documentation. I
> would be very against having the framework do a cast as has been suggested
> on here, because that is a hack, and not useful for anything - I lose the
> value of generics because the compiler is no longer checking my type
> safety
> throughout the application. If I came to a framework without previous
> experience with it, and discovered that ugly hack, I would be worried
> about
> the quality of all of the code.
>
> I think that we should:
> - continue with 1.4-M2
> - create a wiki page where we can get one master list of things we like
> and don't like
> - see what we can do to address those
>
> We're really not getting anywhere with this conversation until we have a
> finite list, and some options for each con on the list. Then we can
> either
> choose the best options or say "forget it".
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten <[EMAIL PROTECTED]>
> wrote:
>
>>
>> hi sebastiaan,
>>
>> I'm very much against using generics to do something other from what
>>> generics where meant to do (i.e., type safety).
>>>
>>
>> i'm all in when you're talking about type safety. having compile-time
>> checks on the types is a time-saver during development.
>>
>> with wicket generics it's just that the time-saver get's in it's own way,
>> i.e. bringing in so much boilerplate, that coding is getting harder to do
>> right (besides from source readability).
>>
>>
>> regards, --- jan.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17406422.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 can i load Image??
Thank you for your help, I will try your solution :) -- View this message in context: http://www.nabble.com/How-can-i-load-Image---tp17403872p17406121.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: unit testing setRenderResponse(new Page()) without instantiation of Page
You could use the bookmarkable version of setResponsePage(). That
just says what type of page to instantiate.
On Thu, May 22, 2008 at 10:51 AM, nitinkc <[EMAIL PROTECTED]> wrote:
>
> I am looking to unit test the following:
>
>form.add(new AjaxSubmitLink("submitLink"){
>private static final long serialVersionUID =
> 3239568065916265026L;
>
>@Override
>protected void onSubmit(AjaxRequestTarget target, Form
> form){
>setResponsePage(new ScheduleEvent(event,
> resources));
>}
>
> Calling
> tester.clickLink("submitLink", true);
>
> instantiates the ScheduleEvent class. I want to avoid this as it forces me
> to mock appropriate parameters for ScheduleEvent. All I want to do is check
> that the rendered page is of type ScheduleEvent. ScheduleEvent class will
> have it's own unit tests where I want to address issues concerning it. Has
> anyone done this??
> --
> View this message in context:
> http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
unit testing setRenderResponse(new Page()) without instantiation of Page
I am looking to unit test the following:
form.add(new AjaxSubmitLink("submitLink"){
private static final long serialVersionUID =
3239568065916265026L;
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form){
setResponsePage(new ScheduleEvent(event,
resources));
}
Calling
tester.clickLink("submitLink", true);
instantiates the ScheduleEvent class. I want to avoid this as it forces me
to mock appropriate parameters for ScheduleEvent. All I want to do is check
that the rendered page is of type ScheduleEvent. ScheduleEvent class will
have it's own unit tests where I want to address issues concerning it. Has
anyone done this??
--
View this message in context:
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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: (Class>) casting troubles
Well, perhaps if we documented our specific usecases, it might help the case for change (that's assuming there aren't already a million other people doing the same thing ;). I think creating the Wiki is a good idea. It will help us identify the growing pains we're facing and perhaps let folks propose solutions. Or, if the growing pains are too numerous (which could very well be the case), we may decide that it's just not worth it. On Thu, May 22, 2008 at 10:42 AM, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > Yes. I think trying to fix this "problem" is really trying to fix Java, which > is pretty far outside our scope. Sun Microsystems should be trying to fix > such use cases not us. If people are leaving the Java platform because of > verbosity my guess is such people left when they saw their first anonymous > class, but that's just my opinion. > > In the case at hand, if we're doing generics where it's an unreasonable use > case, that's one thing. We can fix that. But I think a class like component > is almost certainly a reasonable use case and if we can't come to an > agreement to make that generic, there's something more deeply wrong with > Java generics which we can't fix and so the only reasonable course of action > at that point is to scrap generics entirely for now and wait for Sun > Microsystems to fix it (which is the reason I asked if we could not create a > version with the generics removed). Personally, I don't see this use of Void > as something even remotely close to a reason to scrap it. I would happily > use that construct every day. But that's just me. > > > Sebastiaan van Erk wrote: >> >> Jan Kriesten wrote: >>> >>> hi johan, >>> But if you have a lot of Link for you cases then make 1 simple subclass of Link >>> >>> so anyone make your own wrapper to get readable sources again? let me >>> think: how many webmarkupcontainer, link, page etc. classes do i use >>> with void? >>> >>> i don't think that's a serious option. >> >> While Link is somewhat more verbose than Link, I seriously think >> that people are making too big a deal out of it. Is Link really >> that unreadable? Is it really that hard to code? Personally I think >> *adds* to the clarity; it says you're not going to use the model of the >> Link component. >> >> Regards, >> Sebastiaan >> >>> --- jan. >>> >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> >> > > -- > View this message in context: > http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.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]
Re: (Class>) casting troubles
Yes. I think trying to fix this "problem" is really trying to fix Java, which is pretty far outside our scope. Sun Microsystems should be trying to fix such use cases not us. If people are leaving the Java platform because of verbosity my guess is such people left when they saw their first anonymous class, but that's just my opinion. In the case at hand, if we're doing generics where it's an unreasonable use case, that's one thing. We can fix that. But I think a class like component is almost certainly a reasonable use case and if we can't come to an agreement to make that generic, there's something more deeply wrong with Java generics which we can't fix and so the only reasonable course of action at that point is to scrap generics entirely for now and wait for Sun Microsystems to fix it (which is the reason I asked if we could not create a version with the generics removed). Personally, I don't see this use of Void as something even remotely close to a reason to scrap it. I would happily use that construct every day. But that's just me. Sebastiaan van Erk wrote: > > Jan Kriesten wrote: >> >> hi johan, >> >>> But if you have a lot of Link for you cases >>> then make 1 simple subclass of Link >> >> so anyone make your own wrapper to get readable sources again? let me >> think: how many webmarkupcontainer, link, page etc. classes do i use >> with void? >> >> i don't think that's a serious option. > > While Link is somewhat more verbose than Link, I seriously think > that people are making too big a deal out of it. Is Link really > that unreadable? Is it really that hard to code? Personally I think > *adds* to the clarity; it says you're not going to use the model of the > Link component. > > Regards, > Sebastiaan > >> --- jan. >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > -- View this message in context: http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.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: Data Access Design for Pagination
Why can't you just query for the objects that should be on the page? On Thu, May 22, 2008 at 9:51 AM, wfroud <[EMAIL PROTECTED]> wrote: > > Hi, > > I've been using the DefaultDataTable component in Wicket which allow me to > paginate through a few pages worth of multi column data. > > I believe the general approach is to load all data from the database into > the session first (as a List of Domain Objects ?), then as navigation links > are clicked show subsets of this list? > > I'm using Spring Beans Injection to inject the Data Access Object into a > subclass of SortableDataProvider (called QueryDataProvider). > > Then within the QueryDataProviders constructor I'm calling a method in the > DataAccessObject to create the List of Data Objects. > > The DataProvider's iterator method then calls a subset of the List stored in > the DataAccessObject. > > I'm pretty sure this is an awful way of designing my data access, if I click > the nav links just a bit too fast I get the following error: > > WicketMessage: After 1 minute the Pagemap null is still locked by: > Thread[http-8080-1,5,main], giving up trying to get the page for path: > 16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink > > How should I be doing things differently? > > Thanks for any help, much appreciated. > > Will > -- > View this message in context: > http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.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]
Re: Formatting a DatePickerSettings
Hi Nate, I think you have to create/override the factor method in DateTextField
and set it from there:
protected DateTextField newDateTextField(String id, PropertyModel
dateFieldModel)
{
return new DateTextField(id, dateFieldModel, new
StyleDateConverter(false)).forDatePattern(id,dateFieldModel, "MM/dd"yy");
}
Hope this helps!
Regards,
Wen Tong--
The only constant in life is change.
- Original Message
From: nate roe <[EMAIL PROTECTED]>
To: users@wicket.apache.org
Sent: Wednesday, May 21, 2008 3:38:00 PM
Subject: Formatting a DatePickerSettings
I'm using Wicket 1.2, and WicketExtensions 1.2.
I have a DateTextField that is formatted with the String, "MM/dd/yy" This
field has a corresponding DatePickerSettings, but the DatePickerSettings
doesn't follow this format (it adds dates with four-digit years,
"MM/dd/".)
How can I change this?
Thanks,
Nate
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can i load Image??
I hope I'm getting your point right ...
I think the solution for your problem is to mount the resource. E.g. in your
application class (if it's a logo that's reused often in the app ... and
also comes with the app)
final String name = "foo.jpg";
getSharedResources().add(name, PackageResource.get(YourClassScope.class,
name));
mountSharedResource("/img/" + name, new ResourceReference(name)
.getSharedResourceKey());
then you can access it with "/img/foo.jpg" in your html or in your
StaticImages and so on ... again, hope I got your point :-)
Fabien D. wrote:
>
> Hi everybody,
>
> In my web application, I want to display a Image.
>
> I try to use Image and ResourceReference but I have some problemes
>
> My image is in a folder "stock" in my context of my web aplication :
>
> /stock/domaine/sdoimaine/projet/logo. I try to load it with the real path,
> or the context path...
>
> String name_upload = GestionProperties.getProperty("uploadRealdir");
> String chemin =
> name_upload+File.separator+model_domaine.getObject()+File.separator+model_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.separator+model_logo.getObject();
> ResourceReference ref = new ResourceReference(chemin);
> Image logoProjet = new Image("logoimg", ref );
>
> And the result is :
> http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Application/stock...
>
> How can I place my RessourceReference in the context?
>
> Thank you in adance
>
-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:
http://www.nabble.com/How-can-i-load-Image---tp17403872p17405297.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: (Class>) casting troubles
Jeremy Thomerson wrote: I haven't said anything up to this point, but we really don't seem to be getting anywhere with what is turning into a religious war. I, for one, have already started using 1.4, and love the generics, despite the extra verbosity. It gives me extra type safety and code self-documentation. I would be very against having the framework do a cast as has been suggested on here, because that is a hack, and not useful for anything - I lose the value of generics because the compiler is no longer checking my type safety throughout the application. If I came to a framework without previous experience with it, and discovered that ugly hack, I would be worried about the quality of all of the code. I think that we should: - continue with 1.4-M2 - create a wiki page where we can get one master list of things we like and don't like - see what we can do to address those We're really not getting anywhere with this conversation until we have a finite list, and some options for each con on the list. Then we can either choose the best options or say "forget it". I agree with the above points. Furthermore, we're not really getting any idea about how the community feels about generics. A vocal minority speaks up. On the list, things tend to be biased towards the problems and not the things working well (the people happily going about their business without issues are less likely to be reading along and posting their experiences). There were about 100 votes +1 *quick* generic release and I don't see very many complaints. Why not wait a bit, polish some of the rough edges and have a poll or something to ask the community how they feel... Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Data Access Design for Pagination
Hi, I've been using the DefaultDataTable component in Wicket which allow me to paginate through a few pages worth of multi column data. I believe the general approach is to load all data from the database into the session first (as a List of Domain Objects ?), then as navigation links are clicked show subsets of this list? I'm using Spring Beans Injection to inject the Data Access Object into a subclass of SortableDataProvider (called QueryDataProvider). Then within the QueryDataProviders constructor I'm calling a method in the DataAccessObject to create the List of Data Objects. The DataProvider's iterator method then calls a subset of the List stored in the DataAccessObject. I'm pretty sure this is an awful way of designing my data access, if I click the nav links just a bit too fast I get the following error: WicketMessage: After 1 minute the Pagemap null is still locked by: Thread[http-8080-1,5,main], giving up trying to get the page for path: 16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink How should I be doing things differently? Thanks for any help, much appreciated. Will -- View this message in context: http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.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: (Class>) casting troubles
I forgot to mention... when I said code self-documentation, I meant that there are places where I have a component or page that takes two models. Which is which? I document it by the parameter name (i.e. MyComponent(IModel fooModel, IModel barModel), but it is much better (and the compiler checks it for me) having MyComponent(IModel fooModel, IModel barModel). -- Jeremy Thomerson http://www.wickettraining.com On Thu, May 22, 2008 at 8:32 AM, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > I haven't said anything up to this point, but we really don't seem to be > getting anywhere with what is turning into a religious war. I, for one, > have already started using 1.4, and love the generics, despite the extra > verbosity. It gives me extra type safety and code self-documentation. I > would be very against having the framework do a cast as has been suggested > on here, because that is a hack, and not useful for anything - I lose the > value of generics because the compiler is no longer checking my type safety > throughout the application. If I came to a framework without previous > experience with it, and discovered that ugly hack, I would be worried about > the quality of all of the code. > > I think that we should: > - continue with 1.4-M2 > - create a wiki page where we can get one master list of things we like > and don't like > - see what we can do to address those > > We're really not getting anywhere with this conversation until we have a > finite list, and some options for each con on the list. Then we can either > choose the best options or say "forget it". > > -- > Jeremy Thomerson > http://www.wickettraining.com > > On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten <[EMAIL PROTECTED]> > wrote: > >> >> hi sebastiaan, >> >> I'm very much against using generics to do something other from what >>> generics where meant to do (i.e., type safety). >>> >> >> i'm all in when you're talking about type safety. having compile-time >> checks on the types is a time-saver during development. >> >> with wicket generics it's just that the time-saver get's in it's own way, >> i.e. bringing in so much boilerplate, that coding is getting harder to do >> right (besides from source readability). >> >> >> regards, --- jan. >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > >
Re: (Class>) casting troubles
I haven't said anything up to this point, but we really don't seem to be getting anywhere with what is turning into a religious war. I, for one, have already started using 1.4, and love the generics, despite the extra verbosity. It gives me extra type safety and code self-documentation. I would be very against having the framework do a cast as has been suggested on here, because that is a hack, and not useful for anything - I lose the value of generics because the compiler is no longer checking my type safety throughout the application. If I came to a framework without previous experience with it, and discovered that ugly hack, I would be worried about the quality of all of the code. I think that we should: - continue with 1.4-M2 - create a wiki page where we can get one master list of things we like and don't like - see what we can do to address those We're really not getting anywhere with this conversation until we have a finite list, and some options for each con on the list. Then we can either choose the best options or say "forget it". -- Jeremy Thomerson http://www.wickettraining.com On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > hi sebastiaan, > > I'm very much against using generics to do something other from what >> generics where meant to do (i.e., type safety). >> > > i'm all in when you're talking about type safety. having compile-time > checks on the types is a time-saver during development. > > with wicket generics it's just that the time-saver get's in it's own way, > i.e. bringing in so much boilerplate, that coding is getting harder to do > right (besides from source readability). > > > regards, --- jan. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Wicket and inline JavaScript
Hi Ned,
thanks for your reply. I agree with your point of view. Today, however,
we got bitten because the designer wanted to change all buttons by
hiding them with jquery, and adding an anchor right after it in the
dom-tree, so he could style them the way he wanted it (not possible with
buttons he tells me).
You can see his lovely button on this page:
http://sd.tornado.no/domorder/search/query/testdomain
The way he then triggered the submit buttons is with the following
Jquery code:
$('.btn.submit').click(function(){
$(this).prev().click();
});
This works most of the times, but sometimes, when the wicket ajax stuff
includes references to 'this', the approach doesn't work, and wicket
tells me that the ajax request was stopped 'because of precondition'.
That's when he started bitching about the Wicket way of inlining
JavaScript, so I thought I'd be nice to hear some opinions :))
-- Edvin
Ned Collyer skrev:
Hi Edvin,
I am an advocate of JQuery :). I even won their icon design contest, and
I've been using it for years! I think it should be used in all projects
that require effects or cool DOM manipulation.
I love the "unobtrusive way" and xhtml strict!
That being said, when it comes to wicket AJAX - just use the wicket ajax and
be done with it. No point mucking with something thats already excellent.
It works and its easy. Why reimplement that bit - and potentially open up
bugs that you need to go debug.
For effects and DOM manipulation, you can use JQuery by adding header
contributors. It is cleaner.. and in many instances easier to debug. It
makes development quick and painless.
If it wasn't wicket - id suggest using JQuery for ajax.
Edvin Syse wrote:
Hi,
I have a webdesigner who keeps harassing me with the way Wicket does
JavaScript, attaching behaviour to onclick events etc. instead of doing
it "the jquery way" of picking up the components and attaching the
events afterwards, thus keeping all the nasty bits away from the actual
markup.
Ofcourse the code looks a lot cleaner "the jquery way", and he tells me
that debugging and working with the code is also much easier. Personally
I don't know enough about html/javascript to decide what's the better
approach, but I just wanted to know if there are any plans to rework
this in Wicket, or if the current approach is just as good?
-- Edvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How can i load Image??
Why not do:
final Image logoImg = new Image("logoimg");
logoImg.add(new SimpleAttributeModifier("src", chemin));
or:
final Image logoImg = new Image("logoimg");
logoImg.add(new AttributeModifier("src", true, new
AbstractReadOnlyModel() {
public final Object getObject() {
// TODO : get the image source that will be updated
dynamically
return chemin;
}
}));
-Original Message-
From: Fabien D. [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 9:08 AM
To: users@wicket.apache.org
Subject: How can i load Image??
Hi everybody,
In my web application, I want to display a Image.
I try to use Image and ResourceReference but I have some problemes
My image is in a folder "stock" in my context of my web aplication :
/stock/domaine/sdoimaine/projet/logo. I try to load it with the real
path, or the context path...
String name_upload = GestionProperties.getProperty("uploadRealdir");
String chemin =
name_upload+File.separator+model_domaine.getObject()+File.separator+mode
l_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.sep
arator+model_logo.getObject();
ResourceReference ref = new ResourceReference(chemin);
Image logoProjet = new Image("logoimg", ref );
And the result is :
http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Applicat
ion/stock...
How can I place my RessourceReference in the context?
Thank you in adance
--
View this message in context:
http://www.nabble.com/How-can-i-load-Image---tp17403872p17403872.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]
Re: Testing using WicketTester
See the testing section here
http://cwiki.apache.org/WICKET/spring.html#Spring-UnitTestingtheProxyApproach
For testing spring.
Basically you make a context, and add it to the app. You can load it up
with whatever real/mock beans you need.
Rgds
Ned
Eyal Golan wrote:
>
> Thanks.
> I actually tried but got an error that it could not find the application
> context (we use Spring).
>
> java.lang.IllegalStateException: No WebApplicationContext found: no
> ContextLoaderListener registered?
>
> Instead this is what I did:
> tester = new WicketTester(new WebApplication() {
> @Override
> public Session newSession(Request request, Response response)
> {
> return new PortalSession(request);
> }
>
> @Override
> public Class getHomePage() {
> // TODO Auto-generated method stub
> return null;
> }
>
> });
>
> What do you think?
>
--
View this message in context:
http://www.nabble.com/Testing-using-WicketTester-tp17403637p17404126.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: Wicket and inline JavaScript
Hi Edvin, I am an advocate of JQuery :). I even won their icon design contest, and I've been using it for years! I think it should be used in all projects that require effects or cool DOM manipulation. I love the "unobtrusive way" and xhtml strict! That being said, when it comes to wicket AJAX - just use the wicket ajax and be done with it. No point mucking with something thats already excellent. It works and its easy. Why reimplement that bit - and potentially open up bugs that you need to go debug. For effects and DOM manipulation, you can use JQuery by adding header contributors. It is cleaner.. and in many instances easier to debug. It makes development quick and painless. If it wasn't wicket - id suggest using JQuery for ajax. Edvin Syse wrote: > > Hi, > > I have a webdesigner who keeps harassing me with the way Wicket does > JavaScript, attaching behaviour to onclick events etc. instead of doing > it "the jquery way" of picking up the components and attaching the > events afterwards, thus keeping all the nasty bits away from the actual > markup. > > Ofcourse the code looks a lot cleaner "the jquery way", and he tells me > that debugging and working with the code is also much easier. Personally > I don't know enough about html/javascript to decide what's the better > approach, but I just wanted to know if there are any plans to rework > this in Wicket, or if the current approach is just as good? > > -- Edvin > -- View this message in context: http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17404025.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: filter for data in security layer
Hi,
thanks a lot for the detailed explanation, it works
I needed some time for the implementation, because I'm a wicket beginner and
had first to find out, how a DropDownChoice works (not so easy to understand
that model concept at the first time :))
Only one point regarding to the policy file is open:
If I use the name of the DataPermission defined in the Model (like in the
"Getting started with Swarm" example), it works.
This makes sense in the case of my Location DropDownChoice, because this is
created within the SecureBasePage, which is extended by each page.
One user has always the same permissions for the locations on each page (all
locations or only certain locations).
So I have to define the permission only once for the Model (per principal), but
not for every page.
public class LocationListModel extends LoadableDetachableModel implements
SwarmModel {
...
public String getSecurityId(Component component) {
return "LocationListModel"; // name of the DataPermission
}
...
}
permission ${DataPermission} "LocationListModel", "global";
--
I tried to set the permissions like in the explanation below, but that didn't
work:
// Welcome page
permission ${ComponentPermission} "${front}.Welcome", "inherit, render, global";
permission ${ComponentPermission} "${front}.Welcome", "enable, global";
Debug logging:
2008-05-22 14:47:57,515 DEBUG
org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) -
Adding
org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
"xxx.yyy.zzz.front.Welcome" "access, render, enable, location, global" to
everybody
2008-05-22 14:47:57,515 DEBUG
org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) -
Adding
org.apache.wicket.security.hive.authorization.permissions.ComponentPermission
"xxx.yyy.zzz.front.Welcome" "access, inherit, render, location, global" to
everybody
2008-05-22 14:48:13,046 DEBUG
org.apache.wicket.Component.render(Component.java:2284) - Begin render
[MarkupContainer [Component id = selectLocation, page =
xxx.yyy.zzz.front.Welcome, path = 1:formLocation:selectLocation.DropDownChoice,
isVisible = true, isVersioned = false]]
2008-05-22 14:48:13,046 DEBUG
org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:224) -
Subjects[HashKey: -1185945692, sortOrder 0 = [EMAIL PROTECTED] [mailto:[EMAIL
PROTECTED] does not have or implies
org.apache.wicket.security.hive.authorization.permissions.DataPermission
"LocationListModel" "global"
Andrea
-
On Sun, May 18, 2008 at 7:26 PM, Igor Vaynberg <[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]> wrote:
> something like this should probably be filter inside the database not
> by some external filter which forces you to load the entire dataset.
No that would be foolish, but that wasn't suggested.
>
> -igor
>
> On Sun, May 18, 2008 at 9:39 AM, Andrea Jahn <[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>> Hi,
>>
>> in our application locations are administered. A user has only rights on
>> some of the locations, e.g. Munich, Berlin. He should be able to select one
>> of the allowed locations in a selection box. Then on the different pages all
>> data are depending on the actually selected location. For example a DataView
>> shows only the items, which belong to this location.
>>
>> Could Swarm support data filtering ?
Yes, especially in 1.3.1 this is a bit cleaner dependency wise. But
there is no out of the box solution as there are lots of framework
combinations possible. So get ready for some heavy duty programming :)
>>
>> I found the following related message.
>>
>> http://markmail.org/message/hb42u5xj7xlvumm7
>> [http://markmail.org/message/hb42u5xj7xlvumm7]
>> [http://markmail.org/message/hb42u5xj7xlvumm7] (subsection4)
>>
>> I like the idea, that the dataproviders get some filters (only the data
>> which are needed should be read from the database), but where should I store
>> the filters for the actual selected location in the security layer ?
>>
>> Perhaps does someone know examples for that issue (using Wicket, Spring and
>> Hibernate) ?
Not aware of any examples out there, but here is what we did,
customized to your situation for as far as i understand it :)
Suppose we have a searchpage with some filter criteria including a
dropdown for the location. The data in this dropdown is filtered by
the permissions the user has for this page. If he has "global"
permissions the dropdown contains all locations. otherwise it only
contains locations assigned to this user. The user is not required to
select a location, if he does that location will be used but if he
clears the selection the search will be over all allowed locations.
clicking a row in the search results will bring him to a another page
from where he can navigate to other pages to see different data. These
pages can have different permissions as the search page. for example a
user has "global" search an
How can i load Image??
Hi everybody,
In my web application, I want to display a Image.
I try to use Image and ResourceReference but I have some problemes
My image is in a folder "stock" in my context of my web aplication :
/stock/domaine/sdoimaine/projet/logo. I try to load it with the real path,
or the context path...
String name_upload = GestionProperties.getProperty("uploadRealdir");
String chemin =
name_upload+File.separator+model_domaine.getObject()+File.separator+model_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.separator+model_logo.getObject();
ResourceReference ref = new ResourceReference(chemin);
Image logoProjet = new Image("logoimg", ref );
And the result is :
http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Application/stock...
How can I place my RessourceReference in the context?
Thank you in adance
--
View this message in context:
http://www.nabble.com/How-can-i-load-Image---tp17403872p17403872.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: Testing using WicketTester
Thanks.
I actually tried but got an error that it could not find the application
context (we use Spring).
java.lang.IllegalStateException: No WebApplicationContext found: no
ContextLoaderListener registered?
Instead this is what I did:
tester = new WicketTester(new WebApplication() {
@Override
public Session newSession(Request request, Response response) {
return new PortalSession(request);
}
@Override
public Class getHomePage() {
// TODO Auto-generated method stub
return null;
}
});
What do you think?
On Thu, May 22, 2008 at 3:56 PM, richardwilko <
[EMAIL PROTECTED]> wrote:
>
> WicketTester tester = new WicketTester(new MyApplication());
>
> should do it
>
>
>
>
> Eyal Golan wrote:
> >
> > Hi,
> > I want to create a small UnitTest for my login page:
> > public void testLoginPageRender() {
> > tester.startPage(Login.class);
> > // Just to ensure that the request has not been
> > // intercepted or redirected
> > tester.assertRenderedPage(Login.class);
> > // A page might render with an error message.
> > // If the Login page does have an associated error message, the
> > // following
> > // method will result in a failed assertion.
> > tester.assertNoErrorMessage();
> > }
> >
> > I get a ClassCastException:
> > java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
> > at com.eurekify.web.Login.(Login.java:101)
> >
> > And this is of course because I have this in my Login page:
> > if(((PortalSession)getSession()).isUserLoggedIn()){
> > PageParameters pageParameters = new PageParameters();
> > pageParameters.put("pageId", "");
> > PortalWebPage page = new PortalWebPage(pageParameters);
> > setRedirect( true );
> > setResponsePage(page);
> > }
> >
> > My question is, how do I set the WebSession in a testing environment?
> >
> > Thanks
> > --
> > Eyal Golan
> > [EMAIL PROTECTED]
> >
> > Visit: http://jvdrums.sourceforge.net/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Testing-using-WicketTester-tp17403637p17403686.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]
>
>
--
Eyal Golan
[EMAIL PROTECTED]
Visit: http://jvdrums.sourceforge.net/
RE: Providing IModel to Validators
done: https://issues.apache.org/jira/browse/WICKET-1654
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 8:10 PM
To: users@wicket.apache.org
Subject: Re: Providing IModel to Validators
ah, i see. so the model for the validator overrides the message
completely?
i have already built in a support for this into the core api via
IValidationError. the problem is that our validator implementations are
based around resource keys, and changing that will probably entail api
breakages which we cannot have in a 1.3 release.
enter an rfe and we can refactor this stuff for 1.4/1.5
-igor
On Wed, May 21, 2008 at 5:00 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> A "column" attribute, or any other attribute for that matter, would
> not make a difference because if would all be encapsulated within the
> model set on the validator (use case 6 below). Providing models to the
> validators would make it a lot easier to override validation messages
> because all the developer would have to do is set the model on it (vs
> looking up the resource key and add it to the components properties
> file). I can see that this is receiving some strong resistance so I
> wont push the issue any further :o)
>
> ==
>
> Use Case 6:
>
> StringResourceModel srm = new
> StringResourceModel("CustomStringValidator.minimum", null, null, new
> Object[]{ rowIndex, columnIndex });
>
> add(new textfield("fname").setlabel(new model("first
> name")).add(stringvalidator.minimum(5, srm));
>
> results in- 'first name' with value 'abc' at row 10, column 3 is
> shorter than the minimum of 5 characters.
>
> ==
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 21, 2008 3:07 PM
> To: users@wicket.apache.org
> Subject: Re: Providing IModel to Validators
>
> and what happens when someone wants ${label} at row {0} column {1} is
> required? do we start passing in arrays, lists, or maps for imodels to
> validators?
>
> why not just do
>
> textfield.setlabel(new model("first name at row "+row));
>
> -igor
>
> On Wed, May 21, 2008 at 4:52 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>> What I'm proposing would not require the same "first name" model on
>> both validators. I might not have been clear enough in my
> explanation...
>>
>> StringValidator.minimum='${label}' with value '${input}' is shorter
>> than the minimum of ${minimum} characters.
>>
>> CustomStringValidator.minimum='${label}' with value '${input}' at row
>> {0} is shorter than the minimum of ${minimum} characters.
>>
>> MyUsernameValidator.unique='${label}' with value '${input}' at row
>> {0}
>
>> is not unique.
>>
>> ==
>>
>> Use Case 1:
>>
>> add(new textfield("fname").add(stringvalidator.minimum(5));
>>
>> results in- 'fNameId' with value 'abc' is shorter than the minimum of
>> 5 characters.
>>
>> ==
>>
>> Use Case 2:
>>
>> add(new textfield("fname").setlabel(new model("first
>> name")).add(stringvalidator.minimum(5));
>>
>> results in- 'first name' with value 'abc' is shorter than the minimum
>> of
>> 5 characters.
>>
>> ==
>>
>> Use Case 3:
>>
>> StringResourceModel srm = new
>> StringResourceModel("CustomStringValidator.minimum", null, null, new
>> Object[]{ rowIndex });
>>
>> add(new textfield("fname").add(stringvalidator.minimum(5, srm));
>>
>> results in- 'fNameId' with value 'abc' at row 10 is shorter than the
>> minimum of 5 characters.
>>
>> ==
>>
>> Use Case 4:
>>
>> StringResourceModel srm = new
>> StringResourceModel("CustomStringValidator.minimum", null, null, new
>> Object[]{ rowIndex });
>>
>> add(new textfield("fname").setlabel(new model("first
>> name")).add(stringvalidator.minimum(5, srm));
>>
>> results in- 'first name' with value 'abc' at row 10 is shorter than
>> the minimum of 5 characters.
>>
>> ==
>>
>> Use Case 5:
>>
>> StringResourceModel srm = new
>> StringResourceModel("CustomStringValidator.minimum", null, null, new
>> Object[]{ rowIndex });
>>
>> add(new textfield("fname").setlabel(new model("first
>> name")).add(stringvalidator.minimum(5, srm)).add(new
>> MyUsernameValidator());
>>
>> results in- 'first name' with value 'abc' at row 10 is shorter than
>> the minimum of 5 characters.
>>
>> results in- 'first name' with value 'abc' at row 10 is not unique.
>>
>> ==
>>
>> -Original Message-
>> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, May 20, 2008 8:41 PM
>> To: users@wicket.apache.org
>> Subject: Re: Providing IModel to Validators
>>
>> On Tue, May 20, 2008 at 3:39 PM, Hoover, William
>> <[EMAIL PROTECTED]>
>> wrote:
>>> sure, if you know to override NumberValidator.minimum with:
>>>
>>> label.myminimum=My Object at row: {0} with value
>>> NumberValidator.minimum=${label}
Re: Tomcat discards content-type with StringRequestTarget
Great, thanks!
-- Edvin
Johan Compagner skrev:
hmm that is a bug then of StringRequestTarget
It should set that header if the content type is specified.
I will fix that
On Thu, May 22, 2008 at 2:02 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
Update: overriding respond and setting the contentType directly works great
:)
-- Edvin
Edvin Syse skrev:
Sure I could, but since the StringRequestTarget constructor takes a
content-type argument, I find it strange that this isn't sent to the
browser. Sure enough, StringRequestTarget#respond, creates as
StringBufferResourcesStream with the contentType field set correctly, but
then it just copies the stream, and doesn't set any headers.
Maybe this will work?
RequestCycle.get().setRequestTarget(new StringRequestTarget("text/html",
body) {
public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType("text/html");
super.respond(requestCycle);
}
});
-- Edvin
richardwilko skrev:
You could implement your own dynamic web resource. eg for a kml page on
our
site:
public class KMLResource extends DynamicWebResource
{
Document kml;
public KMLResource(Document kml)
{
this.kml = kml;
}
@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}
class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return "application/vnd.google-earth.kml+xml";
}
private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
@Override
public int getLength()
{
return data.length;
}
}
}
then use it like this in your page
final KMLResource kmlResource = new KMLResource(kml);
getRequestCycle().setRequestTarget(new IRequestTarget() {
public void detach(RequestCycle requestCycle) {
}
public void respond(RequestCycle requestCycle) {
ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName("name");
getRequestCycle().setRequestTarget(target); }
});
just alter it for text rather than a Document
-
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]
Re: Testing using WicketTester
WicketTester tester = new WicketTester(new MyApplication());
should do it
Eyal Golan wrote:
>
> Hi,
> I want to create a small UnitTest for my login page:
> public void testLoginPageRender() {
> tester.startPage(Login.class);
> // Just to ensure that the request has not been
> // intercepted or redirected
> tester.assertRenderedPage(Login.class);
> // A page might render with an error message.
> // If the Login page does have an associated error message, the
> // following
> // method will result in a failed assertion.
> tester.assertNoErrorMessage();
> }
>
> I get a ClassCastException:
> java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
> at com.eurekify.web.Login.(Login.java:101)
>
> And this is of course because I have this in my Login page:
> if(((PortalSession)getSession()).isUserLoggedIn()){
> PageParameters pageParameters = new PageParameters();
> pageParameters.put("pageId", "");
> PortalWebPage page = new PortalWebPage(pageParameters);
> setRedirect( true );
> setResponsePage(page);
> }
>
> My question is, how do I set the WebSession in a testing environment?
>
> Thanks
> --
> Eyal Golan
> [EMAIL PROTECTED]
>
> Visit: http://jvdrums.sourceforge.net/
>
>
--
View this message in context:
http://www.nabble.com/Testing-using-WicketTester-tp17403637p17403686.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]
Testing using WicketTester
Hi,
I want to create a small UnitTest for my login page:
public void testLoginPageRender() {
tester.startPage(Login.class);
// Just to ensure that the request has not been
// intercepted or redirected
tester.assertRenderedPage(Login.class);
// A page might render with an error message.
// If the Login page does have an associated error message, the
// following
// method will result in a failed assertion.
tester.assertNoErrorMessage();
}
I get a ClassCastException:
java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
at com.eurekify.web.Login.(Login.java:101)
And this is of course because I have this in my Login page:
if(((PortalSession)getSession()).isUserLoggedIn()){
PageParameters pageParameters = new PageParameters();
pageParameters.put("pageId", "");
PortalWebPage page = new PortalWebPage(pageParameters);
setRedirect( true );
setResponsePage(page);
}
My question is, how do I set the WebSession in a testing environment?
Thanks
--
Eyal Golan
[EMAIL PROTECTED]
Visit: http://jvdrums.sourceforge.net/
refreshingview with textfield items that use validatior
how can use refreshingview with textfield items that use validatior? when i use and validator fails all textfield values reset. i want reset every request, but not when validator fails. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat discards content-type with StringRequestTarget
hmm that is a bug then of StringRequestTarget
It should set that header if the content type is specified.
I will fix that
On Thu, May 22, 2008 at 2:02 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
> Update: overriding respond and setting the contentType directly works great
> :)
>
> -- Edvin
>
> Edvin Syse skrev:
>
> Sure I could, but since the StringRequestTarget constructor takes a
>> content-type argument, I find it strange that this isn't sent to the
>> browser. Sure enough, StringRequestTarget#respond, creates as
>> StringBufferResourcesStream with the contentType field set correctly, but
>> then it just copies the stream, and doesn't set any headers.
>>
>> Maybe this will work?
>>
>> RequestCycle.get().setRequestTarget(new StringRequestTarget("text/html",
>> body) {
>>public void respond(RequestCycle requestCycle) {
>>requestCycle.getResponse().setContentType("text/html");
>>super.respond(requestCycle);
>>}
>> });
>>
>> -- Edvin
>>
>> richardwilko skrev:
>>
>>> You could implement your own dynamic web resource. eg for a kml page on
>>> our
>>> site:
>>>
>>>
>>> public class KMLResource extends DynamicWebResource
>>> {
>>>
>>>Document kml;
>>>public KMLResource(Document kml)
>>>{
>>>this.kml = kml;
>>>}
>>>@Override
>>>protected ResourceState getResourceState()
>>>{
>>>final XMLOutputter out = new XMLOutputter();
>>> KMLResourceState kmlResourceState = new KMLResourceState();
>>>try
>>>{
>>>ByteArrayOutputStream byteout = new ByteArrayOutputStream();
>>>out.output(kml, byteout);
>>>kmlResourceState.setData(byteout.toByteArray());
>>>byteout.close();
>>>}
>>>catch (IOException e)
>>>{
>>>e.printStackTrace();
>>>}
>>>return kmlResourceState;
>>>}
>>>
>>>class KMLResourceState extends ResourceState
>>>{
>>>@Override
>>>public String getContentType()
>>>{
>>>return "application/vnd.google-earth.kml+xml";
>>>}
>>>
>>>private byte[] data = new byte[0];
>>>@Override
>>>public byte[] getData()
>>>{
>>>return data;
>>>}
>>>public void setData(byte[] data)
>>>{
>>>this.data = data;
>>>}
>>> @Override
>>>public int getLength()
>>>{
>>>return data.length;
>>>}
>>>}
>>> }
>>>
>>> then use it like this in your page
>>>
>>> final KMLResource kmlResource = new KMLResource(kml);
>>> getRequestCycle().setRequestTarget(new IRequestTarget() {
>>>
>>>public void detach(RequestCycle requestCycle) {
>>> }
>>>public void respond(RequestCycle requestCycle) {
>>> ResourceStreamRequestTarget target = new
>>> ResourceStreamRequestTarget(kmlResource.getResourceStream());
>>>target.setFileName("name");
>>>
>>>getRequestCycle().setRequestTarget(target); }
>>>});
>>>
>>> just alter it for text rather than a Document
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: (Class>) casting troubles
harder to comprehend??
come on, you must be kidding!
Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.
I think if we made Link default that many people would complain..
johan
On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
> It is. If you haven't noticed, about a bazillion folks around the
> world are discarding Java because of its verbosity. Having to type
> Link("link") {} really makes it harder to comprehend. Why does
> the link need a type? It is not needed. what is not needed doesn't
> need to be specified. Period.
>
> Martijn
>
> On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
> wrote:
> > Jan Kriesten wrote:
> >>
> >> hi johan,
> >>
> >>> But if you have a lot of Link for you cases
> >>> then make 1 simple subclass of Link
> >>
> >> so anyone make your own wrapper to get readable sources again? let me
> >> think: how many webmarkupcontainer, link, page etc. classes do i use
> with
> >> void?
> >>
> >> i don't think that's a serious option.
> >
> > While Link is somewhat more verbose than Link, I seriously think
> that
> > people are making too big a deal out of it. Is Link really that
> > unreadable? Is it really that hard to code? Personally I think *adds* to
> the
> > clarity; it says you're not going to use the model of the Link component.
> >
> > Regards,
> > Sebastiaan
> >
> >> --- jan.
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: (Class>) casting troubles
harder to comprehend??
come on, you must be kidding!
Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.
I think if we made Link default that many people would complain..
johan
On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
> It is. If you haven't noticed, about a bazillion folks around the
> world are discarding Java because of its verbosity. Having to type
> Link("link") {} really makes it harder to comprehend. Why does
> the link need a type? It is not needed. what is not needed doesn't
> need to be specified. Period.
>
> Martijn
>
> On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
> wrote:
> > Jan Kriesten wrote:
> >>
> >> hi johan,
> >>
> >>> But if you have a lot of Link for you cases
> >>> then make 1 simple subclass of Link
> >>
> >> so anyone make your own wrapper to get readable sources again? let me
> >> think: how many webmarkupcontainer, link, page etc. classes do i use
> with
> >> void?
> >>
> >> i don't think that's a serious option.
> >
> > While Link is somewhat more verbose than Link, I seriously think
> that
> > people are making too big a deal out of it. Is Link really that
> > unreadable? Is it really that hard to code? Personally I think *adds* to
> the
> > clarity; it says you're not going to use the model of the Link component.
> >
> > Regards,
> > Sebastiaan
> >
> >> --- jan.
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Tomcat discards content-type with StringRequestTarget
Update: overriding respond and setting the contentType directly works
great :)
-- Edvin
Edvin Syse skrev:
Sure I could, but since the StringRequestTarget constructor takes a
content-type argument, I find it strange that this isn't sent to the
browser. Sure enough, StringRequestTarget#respond, creates as
StringBufferResourcesStream with the contentType field set correctly,
but then it just copies the stream, and doesn't set any headers.
Maybe this will work?
RequestCycle.get().setRequestTarget(new StringRequestTarget("text/html",
body) {
public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType("text/html");
super.respond(requestCycle);
}
});
-- Edvin
richardwilko skrev:
You could implement your own dynamic web resource. eg for a kml page
on our
site:
public class KMLResource extends DynamicWebResource
{
Document kml;
public KMLResource(Document kml)
{
this.kml = kml;
}
@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}
class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return "application/vnd.google-earth.kml+xml";
}
private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
@Override
public int getLength()
{
return data.length;
}
}
}
then use it like this in your page
final KMLResource kmlResource = new KMLResource(kml);
getRequestCycle().setRequestTarget(new IRequestTarget() {
public void detach(RequestCycle requestCycle) {
}
public void respond(RequestCycle requestCycle) {
ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName("name");
getRequestCycle().setRequestTarget(target); }
});
just alter it for text rather than a Document
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] wicketstuff SVN reorganization...
James Carman wrote: All, Ok, folks, so where are we on this? There has been some desire to reorganize things a bit. There are at least 3 options that I have heard: 1. Leave everything the way it is. 2. Set everything up the way I suggested (the projects can still have a common parent that's a sibling of theirs like we do in commons) 3. Use a hybrid approach, creating some "umbrella" project that is updated/released with the Wicket releases and follows the Wicket release numbering/schedule. Is this what folks have proposed as solutions? If so, should we start a [VOTE] just to see where we are on these three solutions? +1 James p.s. Sorry to be such a stickler, but I'm one of those folks who has to have order. I can't work until I clean my desk up first! :) The first step is identifying the problem and I'll get right on that when I'm done cleaning up my desk! On Wed, May 21, 2008 at 3:31 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: flattery will get you everywhere -igor On Wed, May 21, 2008 at 12:29 PM, James Carman <[EMAIL PROTECTED]> wrote: With the quick release cycles that Wicket goes through, that just seems weird to me. They should pick a version and go with it. The Wicket team is very good about keeping things fresh. I have been very surprised at how many releases have gone out in my brief experience with Wicket. On Wed, May 21, 2008 at 3:27 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: well, the problem is that most trunks depend on wicket snapshots -igor On Wed, May 21, 2008 at 12:05 PM, James Carman <[EMAIL PROTECTED]> wrote: On Wed, May 21, 2008 at 3:00 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: well, thats what we get for having virtually no entry barrier. for me branching the entire repo with every major release of wicket is much easier because i can do it with one command. if each project has their own tree i am not going to do it. that means when there is an api change in wicket all projects will have to be upgraded or they wont compile. They will compile because they're dependencies are not being modified by the Wicket release. Existing projects (if they don't follow the release cycle of Wicket) can specify whatever version of Wicket they *do* compile/run against. As long as nobody changes that (and nobody checks in messed up code), the project should compile and run just fine against the specified release(s) (remember, you can specify version ranges in Maven, too). - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
It is. If you haven't noticed, about a bazillion folks around the
world are discarding Java because of its verbosity. Having to type
Link("link") {} really makes it harder to comprehend. Why does
the link need a type? It is not needed. what is not needed doesn't
need to be specified. Period.
Martijn
On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Jan Kriesten wrote:
>>
>> hi johan,
>>
>>> But if you have a lot of Link for you cases
>>> then make 1 simple subclass of Link
>>
>> so anyone make your own wrapper to get readable sources again? let me
>> think: how many webmarkupcontainer, link, page etc. classes do i use with
>> void?
>>
>> i don't think that's a serious option.
>
> While Link is somewhat more verbose than Link, I seriously think that
> people are making too big a deal out of it. Is Link really that
> unreadable? Is it really that hard to code? Personally I think *adds* to the
> clarity; it says you're not going to use the model of the Link component.
>
> Regards,
> Sebastiaan
>
>> --- jan.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Jan Kriesten wrote: hi johan, But if you have a lot of Link for you cases then make 1 simple subclass of Link so anyone make your own wrapper to get readable sources again? let me think: how many webmarkupcontainer, link, page etc. classes do i use with void? i don't think that's a serious option. While Link is somewhat more verbose than Link, I seriously think that people are making too big a deal out of it. Is Link really that unreadable? Is it really that hard to code? Personally I think *adds* to the clarity; it says you're not going to use the model of the Link component. Regards, Sebastiaan --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: (Class>) casting troubles
hi johan, But if you have a lot of Link for you cases then make 1 simple subclass of Link so anyone make your own wrapper to get readable sources again? let me think: how many webmarkupcontainer, link, page etc. classes do i use with void? i don't think that's a serious option. --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
hi sebastiaan, I'm very much against using generics to do something other from what generics where meant to do (i.e., type safety). i'm all in when you're talking about type safety. having compile-time checks on the types is a time-saver during development. with wicket generics it's just that the time-saver get's in it's own way, i.e. bringing in so much boilerplate, that coding is getting harder to do right (besides from source readability). regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
But if you have a lot of Link for you cases then make 1 simple subclass of Link johan On Thu, May 22, 2008 at 12:41 PM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > Hi Johan, > > ahh yes thats true i overlooked your changes.. >> then yes currently you have to do new Link (to get rid of the >> warnings) >> > > there are quite annoying many cases of this kind, where you really just > don't need to add models to components and have to boilerplate these with > or anything else. > > So, I can really understand and support Martijns objections to have > Component generified just for the sake of it. > > If it's to clearify the API - make those cases generic or have them > implement a different IModel (like ListModel e.g.). > > Best regards, --- Jan. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Wicket and inline JavaScript
Hi, I have a webdesigner who keeps harassing me with the way Wicket does JavaScript, attaching behaviour to onclick events etc. instead of doing it "the jquery way" of picking up the components and attaching the events afterwards, thus keeping all the nasty bits away from the actual markup. Ofcourse the code looks a lot cleaner "the jquery way", and he tells me that debugging and working with the code is also much easier. Personally I don't know enough about html/javascript to decide what's the better approach, but I just wanted to know if there are any plans to rework this in Wicket, or if the current approach is just as good? -- Edvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Jan Kriesten wrote: Hi Johan, ahh yes thats true i overlooked your changes.. then yes currently you have to do new Link (to get rid of the warnings) there are quite annoying many cases of this kind, where you really just don't need to add models to components and have to boilerplate these with or anything else. So, I can really understand and support Martijns objections to have Component generified just for the sake of it. Well, I'd hardly say it's just for the sake of it! It's *required* to *properly* generify Wicket. Due to the strong coupling in the design of Wicket of a component to a model, when you refer to a component you *must* specify the type of the model... Anything else is just plain bad (and strange) use of generics... :-( If it's to clearify the API - make those cases generic or have them implement a different IModel (like ListModel e.g.). I'm very much against using generics to do something other from what generics where meant to do (i.e., type safety). Regards, Sebastiaan Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: AjaxLink not clickable in IE
I had this exact problem, but it was because the text inside my
tag was inside a tag (at least I think that's what was causing
it). For some reason, IE didn't like that. I had to tell the label
to just spit out its contents.
On Wed, May 21, 2008 at 5:31 PM, Michael Mehrle <[EMAIL PROTECTED]> wrote:
> I've got this AjaxLink:
>
>
>
> fooLink = new AjaxLink("fooLink") {
>
>@Override
>
>public void
> onClick(AjaxRequestTarget target) {
>
>Boolean
> selected = (Boolean) fooCheckBox.getModelObject();
>
>if
> (!selected) {
>
>
> fooCheckBox.setModelObject((new Boolean(true)));
>
>}
>
>
> target.addComponent(fooCheckBox);
>
>// pop up
> the modal
>
>
> showRecurringFooModal(recurringFooModalWindow, target);
>
>}
>
>};
>
>
>
> key="fooLabel" />
>
>
>
> Works fine in Safari and Firefox but in IE it's not clickable - looks
> like a link but the mouse pointer doesn't change and nothing happens
> when clicking. No error message either in IE's JS console or in AJAX.
> Any idea what I'm doing wrong here?
>
>
>
> Michael
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] wicketstuff SVN reorganization...
All, Ok, folks, so where are we on this? There has been some desire to reorganize things a bit. There are at least 3 options that I have heard: 1. Leave everything the way it is. 2. Set everything up the way I suggested (the projects can still have a common parent that's a sibling of theirs like we do in commons) 3. Use a hybrid approach, creating some "umbrella" project that is updated/released with the Wicket releases and follows the Wicket release numbering/schedule. Is this what folks have proposed as solutions? If so, should we start a [VOTE] just to see where we are on these three solutions? James p.s. Sorry to be such a stickler, but I'm one of those folks who has to have order. I can't work until I clean my desk up first! :) The first step is identifying the problem and I'll get right on that when I'm done cleaning up my desk! On Wed, May 21, 2008 at 3:31 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > flattery will get you everywhere > > -igor > > On Wed, May 21, 2008 at 12:29 PM, James Carman > <[EMAIL PROTECTED]> wrote: >> With the quick release cycles that Wicket goes through, that just >> seems weird to me. They should pick a version and go with it. The >> Wicket team is very good about keeping things fresh. I have been very >> surprised at how many releases have gone out in my brief experience >> with Wicket. >> >> On Wed, May 21, 2008 at 3:27 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >>> well, the problem is that most trunks depend on wicket snapshots >>> >>> -igor >>> >>> On Wed, May 21, 2008 at 12:05 PM, James Carman >>> <[EMAIL PROTECTED]> wrote: On Wed, May 21, 2008 at 3:00 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > well, thats what we get for having virtually no entry barrier. for me > branching the entire repo with every major release of wicket is much > easier because i can do it with one command. if each project has their > own tree i am not going to do it. that means when there is an api > change in wicket all projects will have to be upgraded or they wont > compile. They will compile because they're dependencies are not being modified by the Wicket release. Existing projects (if they don't follow the release cycle of Wicket) can specify whatever version of Wicket they *do* compile/run against. As long as nobody changes that (and nobody checks in messed up code), the project should compile and run just fine against the specified release(s) (remember, you can specify version ranges in Maven, too). - 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Hi Johan, ahh yes thats true i overlooked your changes.. then yes currently you have to do new Link (to get rid of the warnings) there are quite annoying many cases of this kind, where you really just don't need to add models to components and have to boilerplate these with or anything else. So, I can really understand and support Martijns objections to have Component generified just for the sake of it. If it's to clearify the API - make those cases generic or have them implement a different IModel (like ListModel e.g.). Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat discards content-type with StringRequestTarget
Sure I could, but since the StringRequestTarget constructor takes a
content-type argument, I find it strange that this isn't sent to the
browser. Sure enough, StringRequestTarget#respond, creates as
StringBufferResourcesStream with the contentType field set correctly,
but then it just copies the stream, and doesn't set any headers.
Maybe this will work?
RequestCycle.get().setRequestTarget(new StringRequestTarget("text/html",
body) {
public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType("text/html");
super.respond(requestCycle);
}
});
-- Edvin
richardwilko skrev:
You could implement your own dynamic web resource. eg for a kml page on our
site:
public class KMLResource extends DynamicWebResource
{
Document kml;
public KMLResource(Document kml)
{
this.kml = kml;
}
@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new
ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}
class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return "application/vnd.google-earth.kml+xml";
}
private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
@Override
public int getLength()
{
return data.length;
}
}
}
then use it like this in your page
final KMLResource kmlResource = new KMLResource(kml);
getRequestCycle().setRequestTarget(new IRequestTarget() {
public void detach(RequestCycle requestCycle) {
}
public void respond(RequestCycle requestCycle) {
ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName("name");
getRequestCycle().setRequestTarget(target);
}
});
just alter it for text rather than a Document
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
ahh yes thats true i overlooked your changes..
then yes currently you have to do new Link (to get rid of the
warnings)
johan
On Thu, May 22, 2008 at 11:54 AM, Jan Kriesten <[EMAIL PROTECTED]>
wrote:
>
> Hi Johan,
>
> But i really dont think that in link is redundant why is it?
>>
>
> the point was, that in this case Link simply doesn't need to have given a
> model at all, since you can access the surrounding final vars (you can
> access the item in onClick):
>
> populateItem(final ListItem item) {
>>> item.add(new Link("edit") {
>>> public void onClick() {
>>> setResponsePage(new EditPage(item.getModelObject()));
>>> }
>>> });
>>>
>>
> What else could you do/access in Link what is not possible with this
> approach?
>
>
>
> Regards, --- Jan.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: (Class>) casting troubles
Hi Johan,
But i really dont think that in link is redundant why is it?
the point was, that in this case Link simply doesn't need to have given a model
at all, since you can access the surrounding final vars (you can access the item
in onClick):
populateItem(final ListItem item) {
item.add(new Link("edit") {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});
What else could you do/access in Link what is not possible with this approach?
Regards, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Yeah that is the problem with Generics
You cant say take the from the model you get in the constructor
Then everything would be perfect.
But i really dont think that in link is redundant why is it?
You call later on getModelObject() on it.. so you use the model/modelobject
of Link
so you need to say what Link has..
johan
On Thu, May 22, 2008 at 11:45 AM, Jan Kriesten <[EMAIL PROTECTED]>
wrote:
>
> Hi Johan,
>
> I thing that the example below is exactly the thing that generics are
>> pretty
>> good:
>>
>> populateItem(ListItem item) {
>> add(new Link("edit", item.getModel()) {
>> public void onClick() {
>> setResponsePage(new EditPage(getModelObject()));
>> }
>> });
>>
>> (and EditPage is by itself already generified to )
>>
>
> well, just that the Link is IMHO redundant and unnecessary(just
> dropped a note to Martijn, but since you brought that up...)
>
> populateItem(final ListItem item) {
>item.add(new Link("edit") {
>public void onClick() {
>setResponsePage(new EditPage(item.getModelObject()));
>}
>});
>
> So, it might have sense with ListItem, but not necissarily with Link...
>
> Regards, --- Jan.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: (Class>) casting troubles
+1 for finishing generics (no matter how ugly it gets), then
refactoring / removing the things that suck
Am 22.05.2008 um 11:37 schrieb Johan Compagner:
exactly Repeaters is very nice that the populateItem is generified..
I think
that is really handy..
And if the EditPage now wanted a specific type then you need now to
cast at
that place..
I thing that the example below is exactly the thing that generics
are pretty
good:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to )
This is just a perfect thing that i say yes very nice you see
exactly what
the code should do
and cant say that this is really verbose..
johan
On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
I often do the following:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}
So both are used often, but mostly to pass things around.
Martijn
On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]
>
wrote:
getModel() i agree, but getModelObject() is something that is used
the
most
if i have to guess.
Because in an onSubmit() of a form or a onClick of a Link what do
most of
you do?
onSubmit()
{
dao.save(getModelObject())
}
onClick()
{
dao.delete(getModelObject())
}
johan
On Thu, May 22, 2008 at 10:05 AM, Matej Knopp
<[EMAIL PROTECTED]>
wrote:
Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...
-Matej
On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]
>
wrote:
I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not
questioning it).
Then in your component subclass you coud do IModel
getModel()
{ return (IModel)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it
would
be safer too).
-Matej
On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <
[EMAIL PROTECTED]>
wrote:
It isnt all or nothing.. i never said that
I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.
But i am also curious how many people get really the model back
from
a
component (not counting specific places like
repeaters.onpopuplate)
because i think most people do component.getModelObject() which
then
needs a
cast
But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.
i think there are 3 options
1> keep it what we have now, tweak it with the feedback we get
from
1.4M2
2> drop it on Component only and have a class like you described
above
to do
this: IModel model =
Unsafe.cast(component.getModel()); (its
still
a hack and a sense of false security but ok. if people really
want
this..)
3> drop it on Component and Model
i am +1 on 1
and -0 on 2 and 3
I still think it is not bad. and you can come around it really
easy
by
just
creating a few extra classes like
StringLabel
NumberLabel
StringTextField
NumberTextField
if you only have a few of those extra all your code is cleanup
johan
On Thu, May 22, 2008 at 9:12 AM, Joni Freeman
<[EMAIL PROTECTED]>
wrote:
Yeah, it could even be in its separate utility class:
interface IModel {}
class Component {
private IModel model;
public IModel getModel() {
return model;
}
}
public class Unsafe {
public static IModel cast(IModel model) {
return (IModel) model;
}
}
class MyComp extends Component {
public MyComp() {
IModel model = Unsafe.cast(getModel());
}
}
I'm merely pointing out that there exists a solution to do
unsafe
cast
without getting compiler warning. Just like normal casts are
handled.
I don't think Johan's all or nothing proposition is very
pragmatic
one.
Without generic IModel we do not get any API discoverability
and our
APIs continue to suck. For instance, how can API user know
what kind
of
model this needs: MyJuicyComponent(String id, IModel model).
At one
point we did this: MyJuicyComponent(String id, IModel/
**/
model) but this convention is far from optimal. To be sure, one
needs
to
browse the sources...
Joni
On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might
have two
methods,
default getModel() that doesn't cast it and alternative
convenience
one that does.
-Matej
On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <
[EMAIL PROTECTED]
wrote:
class Component {
private IModel model;
Re: (Class>) casting troubles
Hi Johan,
I thing that the example below is exactly the thing that generics are pretty
good:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to )
well, just that the Link is IMHO redundant and unnecessary(just dropped
a note to Martijn, but since you brought that up...)
populateItem(final ListItem item) {
item.add(new Link("edit") {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});
So, it might have sense with ListItem, but not necissarily with Link...
Regards, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
exactly Repeaters is very nice that the populateItem is generified.. I think
that is really handy..
And if the EditPage now wanted a specific type then you need now to cast at
that place..
I thing that the example below is exactly the thing that generics are pretty
good:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to )
This is just a perfect thing that i say yes very nice you see exactly what
the code should do
and cant say that this is really verbose..
johan
On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
> I often do the following:
>
> populateItem(ListItem item) {
>add(new Link("edit", item.getModel()) {
>public void onClick() {
>setResponsePage(new EditPage(getModelObject()));
>}
>});
> }
>
> So both are used often, but mostly to pass things around.
>
> Martijn
>
> On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> > getModel() i agree, but getModelObject() is something that is used the
> most
> > if i have to guess.
> >
> > Because in an onSubmit() of a form or a onClick of a Link what do most of
> > you do?
> >
> > onSubmit()
> > {
> > dao.save(getModelObject())
> > }
> >
> > onClick()
> > {
> > dao.delete(getModelObject())
> > }
> >
> > johan
> >
> > On Thu, May 22, 2008 at 10:05 AM, Matej Knopp <[EMAIL PROTECTED]>
> wrote:
> >
> >> Although I'm not sure how many people call getModel/getModelObject
> >> anyway. I think it's mostly about ListItems etc an i doubt anyone
> >> would subclass it just because of getModel/getModelObject...
> >>
> >> -Matej
> >>
> >> On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]>
> >> wrote:
> >> > I would all be easier if getModel() and getModelObject() weren't
> >> > final. (I know there's a reason why they are, I'm not questioning it).
> >> >
> >> > Then in your component subclass you coud do IModel getModel()
> >> > { return (IModel)super.getModel() }, similiar with
> >> > getmodelobject so you wouldn't have casts all over places and it would
> >> > be safer too).
> >> >
> >> > -Matej
> >> >
> >> > On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <
> [EMAIL PROTECTED]>
> >> wrote:
> >> >> It isnt all or nothing.. i never said that
> >> >>
> >> >> I just say if you dont want Component but you do want IModel
> >> >> then you will get a warning at getModel()
> >> >> we as a framework shouldnt hide the warning at that call.
> >> >>
> >> >> But i am also curious how many people get really the model back from
> a
> >> >> component (not counting specific places like repeaters.onpopuplate)
> >> >>
> >> >> because i think most people do component.getModelObject() which then
> >> needs a
> >> >> cast
> >> >>
> >> >> But i like that extra helper method way more then having an extra
> >> >> getUnsafeModel() method..
> >> >> because thats explicit a developer has to really choose for it.
> >> >>
> >> >> i think there are 3 options
> >> >>
> >> >> 1> keep it what we have now, tweak it with the feedback we get from
> >> 1.4M2
> >> >> 2> drop it on Component only and have a class like you described
> above
> >> to do
> >> >> this: IModel model = Unsafe.cast(component.getModel()); (its
> >> still
> >> >> a hack and a sense of false security but ok. if people really want
> >> this..)
> >> >> 3> drop it on Component and Model
> >> >>
> >> >>
> >> >> i am +1 on 1
> >> >> and -0 on 2 and 3
> >> >>
> >> >> I still think it is not bad. and you can come around it really easy
> by
> >> just
> >> >> creating a few extra classes like
> >> >>
> >> >> StringLabel
> >> >> NumberLabel
> >> >> StringTextField
> >> >> NumberTextField
> >> >>
> >> >> if you only have a few of those extra all your code is cleanup
> >> >>
> >> >> johan
> >> >>
> >> >> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]>
> >> wrote:
> >> >>
> >> >>> Yeah, it could even be in its separate utility class:
> >> >>>
> >> >>> interface IModel {}
> >> >>>
> >> >>> class Component {
> >> >>>private IModel model;
> >> >>>
> >> >>> public IModel getModel() {
> >> >>>return model;
> >> >>>}
> >> >>> }
> >> >>>
> >> >>> public class Unsafe {
> >> >>>public static IModel cast(IModel model) {
> >> >>> return (IModel) model;
> >> >>>}
> >> >>> }
> >> >>>
> >> >>> class MyComp extends Component {
> >> >>>public MyComp() {
> >> >>> IModel model = Unsafe.cast(getModel());
> >> >>>}
> >> >>> }
> >> >>>
> >> >>> I'm merely pointing out that there exists a solution to do unsafe
> cast
> >> >>> without getting compiler warning. Just like normal casts are
> handled.
> >> >>>
> >> >>> I don't think Johan's all or nothing proposition is very pragmatic
> one.
> >> >>> Without generic IModel we do not get any API discoverability and our
> >> >>> APIs continue to suck. For instance
Re: javascript error in internet explorer
Johan Compagner wrote: > > is there a jira issue for this patch? > Hello Johan i added an issue for this here https://issues.apache.org/jira/browse/WICKET-1653 WICKET-1653 I have the same error with my ie 6. Will it be fixed in an 1.3 or only in an 1.4 version? Thanks Per -- View this message in context: http://www.nabble.com/javascript-error-in-internet-explorer-tp16732896p17400631.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: (Class>) casting troubles
I often do the following:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}
So both are used often, but mostly to pass things around.
Martijn
On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> getModel() i agree, but getModelObject() is something that is used the most
> if i have to guess.
>
> Because in an onSubmit() of a form or a onClick of a Link what do most of
> you do?
>
> onSubmit()
> {
> dao.save(getModelObject())
> }
>
> onClick()
> {
> dao.delete(getModelObject())
> }
>
> johan
>
> On Thu, May 22, 2008 at 10:05 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
>> Although I'm not sure how many people call getModel/getModelObject
>> anyway. I think it's mostly about ListItems etc an i doubt anyone
>> would subclass it just because of getModel/getModelObject...
>>
>> -Matej
>>
>> On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]>
>> wrote:
>> > I would all be easier if getModel() and getModelObject() weren't
>> > final. (I know there's a reason why they are, I'm not questioning it).
>> >
>> > Then in your component subclass you coud do IModel getModel()
>> > { return (IModel)super.getModel() }, similiar with
>> > getmodelobject so you wouldn't have casts all over places and it would
>> > be safer too).
>> >
>> > -Matej
>> >
>> > On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]>
>> wrote:
>> >> It isnt all or nothing.. i never said that
>> >>
>> >> I just say if you dont want Component but you do want IModel
>> >> then you will get a warning at getModel()
>> >> we as a framework shouldnt hide the warning at that call.
>> >>
>> >> But i am also curious how many people get really the model back from a
>> >> component (not counting specific places like repeaters.onpopuplate)
>> >>
>> >> because i think most people do component.getModelObject() which then
>> needs a
>> >> cast
>> >>
>> >> But i like that extra helper method way more then having an extra
>> >> getUnsafeModel() method..
>> >> because thats explicit a developer has to really choose for it.
>> >>
>> >> i think there are 3 options
>> >>
>> >> 1> keep it what we have now, tweak it with the feedback we get from
>> 1.4M2
>> >> 2> drop it on Component only and have a class like you described above
>> to do
>> >> this: IModel model = Unsafe.cast(component.getModel()); (its
>> still
>> >> a hack and a sense of false security but ok. if people really want
>> this..)
>> >> 3> drop it on Component and Model
>> >>
>> >>
>> >> i am +1 on 1
>> >> and -0 on 2 and 3
>> >>
>> >> I still think it is not bad. and you can come around it really easy by
>> just
>> >> creating a few extra classes like
>> >>
>> >> StringLabel
>> >> NumberLabel
>> >> StringTextField
>> >> NumberTextField
>> >>
>> >> if you only have a few of those extra all your code is cleanup
>> >>
>> >> johan
>> >>
>> >> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]>
>> wrote:
>> >>
>> >>> Yeah, it could even be in its separate utility class:
>> >>>
>> >>> interface IModel {}
>> >>>
>> >>> class Component {
>> >>>private IModel model;
>> >>>
>> >>> public IModel getModel() {
>> >>>return model;
>> >>>}
>> >>> }
>> >>>
>> >>> public class Unsafe {
>> >>>public static IModel cast(IModel model) {
>> >>> return (IModel) model;
>> >>>}
>> >>> }
>> >>>
>> >>> class MyComp extends Component {
>> >>>public MyComp() {
>> >>> IModel model = Unsafe.cast(getModel());
>> >>>}
>> >>> }
>> >>>
>> >>> I'm merely pointing out that there exists a solution to do unsafe cast
>> >>> without getting compiler warning. Just like normal casts are handled.
>> >>>
>> >>> I don't think Johan's all or nothing proposition is very pragmatic one.
>> >>> Without generic IModel we do not get any API discoverability and our
>> >>> APIs continue to suck. For instance, how can API user know what kind of
>> >>> model this needs: MyJuicyComponent(String id, IModel model). At one
>> >>> point we did this: MyJuicyComponent(String id, IModel/**/
>> >>> model) but this convention is far from optimal. To be sure, one needs
>> to
>> >>> browse the sources...
>> >>>
>> >>> Joni
>> >>>
>> >>> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
>> >>> > Well, maybe it really is a hack that's too ugly. We might have two
>> >>> methods,
>> >>> >
>> >>> > default getModel() that doesn't cast it and alternative convenience
>> >>> > one that does.
>> >>> >
>> >>> > -Matej
>> >>> >
>> >>> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]
>> >
>> >>> wrote:
>> >>> > > class Component {
>> >>> > > private IModel model;
>> >>> > >
>> >>> > > public IModel getModel() {
>> >>> > > return (IModel) model;
>> >>> > > }
>> >>> > > }
>> >>> > >
>> >>> > > I like this. Even with the possible class cast exception. Because
>> >>> > > without
Re: (Class>) casting troubles
getModel() i agree, but getModelObject() is something that is used the most
if i have to guess.
Because in an onSubmit() of a form or a onClick of a Link what do most of
you do?
onSubmit()
{
dao.save(getModelObject())
}
onClick()
{
dao.delete(getModelObject())
}
johan
On Thu, May 22, 2008 at 10:05 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Although I'm not sure how many people call getModel/getModelObject
> anyway. I think it's mostly about ListItems etc an i doubt anyone
> would subclass it just because of getModel/getModelObject...
>
> -Matej
>
> On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]>
> wrote:
> > I would all be easier if getModel() and getModelObject() weren't
> > final. (I know there's a reason why they are, I'm not questioning it).
> >
> > Then in your component subclass you coud do IModel getModel()
> > { return (IModel)super.getModel() }, similiar with
> > getmodelobject so you wouldn't have casts all over places and it would
> > be safer too).
> >
> > -Matej
> >
> > On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> >> It isnt all or nothing.. i never said that
> >>
> >> I just say if you dont want Component but you do want IModel
> >> then you will get a warning at getModel()
> >> we as a framework shouldnt hide the warning at that call.
> >>
> >> But i am also curious how many people get really the model back from a
> >> component (not counting specific places like repeaters.onpopuplate)
> >>
> >> because i think most people do component.getModelObject() which then
> needs a
> >> cast
> >>
> >> But i like that extra helper method way more then having an extra
> >> getUnsafeModel() method..
> >> because thats explicit a developer has to really choose for it.
> >>
> >> i think there are 3 options
> >>
> >> 1> keep it what we have now, tweak it with the feedback we get from
> 1.4M2
> >> 2> drop it on Component only and have a class like you described above
> to do
> >> this: IModel model = Unsafe.cast(component.getModel()); (its
> still
> >> a hack and a sense of false security but ok. if people really want
> this..)
> >> 3> drop it on Component and Model
> >>
> >>
> >> i am +1 on 1
> >> and -0 on 2 and 3
> >>
> >> I still think it is not bad. and you can come around it really easy by
> just
> >> creating a few extra classes like
> >>
> >> StringLabel
> >> NumberLabel
> >> StringTextField
> >> NumberTextField
> >>
> >> if you only have a few of those extra all your code is cleanup
> >>
> >> johan
> >>
> >> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]>
> wrote:
> >>
> >>> Yeah, it could even be in its separate utility class:
> >>>
> >>> interface IModel {}
> >>>
> >>> class Component {
> >>>private IModel model;
> >>>
> >>> public IModel getModel() {
> >>>return model;
> >>>}
> >>> }
> >>>
> >>> public class Unsafe {
> >>>public static IModel cast(IModel model) {
> >>> return (IModel) model;
> >>>}
> >>> }
> >>>
> >>> class MyComp extends Component {
> >>>public MyComp() {
> >>> IModel model = Unsafe.cast(getModel());
> >>>}
> >>> }
> >>>
> >>> I'm merely pointing out that there exists a solution to do unsafe cast
> >>> without getting compiler warning. Just like normal casts are handled.
> >>>
> >>> I don't think Johan's all or nothing proposition is very pragmatic one.
> >>> Without generic IModel we do not get any API discoverability and our
> >>> APIs continue to suck. For instance, how can API user know what kind of
> >>> model this needs: MyJuicyComponent(String id, IModel model). At one
> >>> point we did this: MyJuicyComponent(String id, IModel/**/
> >>> model) but this convention is far from optimal. To be sure, one needs
> to
> >>> browse the sources...
> >>>
> >>> Joni
> >>>
> >>> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
> >>> > Well, maybe it really is a hack that's too ugly. We might have two
> >>> methods,
> >>> >
> >>> > default getModel() that doesn't cast it and alternative convenience
> >>> > one that does.
> >>> >
> >>> > -Matej
> >>> >
> >>> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>> > > class Component {
> >>> > > private IModel model;
> >>> > >
> >>> > > public IModel getModel() {
> >>> > > return (IModel) model;
> >>> > > }
> >>> > > }
> >>> > >
> >>> > > I like this. Even with the possible class cast exception. Because
> >>> > > without generics, it doesn't leave you no other option than to cast
> it
> >>> > > to your model, which isn't much better either, as you get the same
> >>> > > result except that it looks uglier.
> >>> > >
> >>> > > -Matej
> >>> > >
> >>> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
> >>> [EMAIL PROTECTED]> wrote:
> >>> > >> no i am really against that falls IModel getModel() method
> >>> > >> that really abuses everything that generics stands for. For such a
> >>> basic
> >>> > >> thing.
> >>> > >> this is reall
Re: (Class>) casting troubles
But if you are willing to subclass it and make that extra method
Then why not subclass the component itself and for example:
IntegerTextField
thats the same thing 1 subclass, no extra generics in your code...
johan
On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> I would all be easier if getModel() and getModelObject() weren't
> final. (I know there's a reason why they are, I'm not questioning it).
>
> Then in your component subclass you coud do IModel getModel()
> { return (IModel)super.getModel() }, similiar with
> getmodelobject so you wouldn't have casts all over places and it would
> be safer too).
>
> -Matej
>
> On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> > It isnt all or nothing.. i never said that
> >
> > I just say if you dont want Component but you do want IModel
> > then you will get a warning at getModel()
> > we as a framework shouldnt hide the warning at that call.
> >
> > But i am also curious how many people get really the model back from a
> > component (not counting specific places like repeaters.onpopuplate)
> >
> > because i think most people do component.getModelObject() which then
> needs a
> > cast
> >
> > But i like that extra helper method way more then having an extra
> > getUnsafeModel() method..
> > because thats explicit a developer has to really choose for it.
> >
> > i think there are 3 options
> >
> > 1> keep it what we have now, tweak it with the feedback we get from 1.4M2
> > 2> drop it on Component only and have a class like you described above to
> do
> > this: IModel model = Unsafe.cast(component.getModel()); (its
> still
> > a hack and a sense of false security but ok. if people really want
> this..)
> > 3> drop it on Component and Model
> >
> >
> > i am +1 on 1
> > and -0 on 2 and 3
> >
> > I still think it is not bad. and you can come around it really easy by
> just
> > creating a few extra classes like
> >
> > StringLabel
> > NumberLabel
> > StringTextField
> > NumberTextField
> >
> > if you only have a few of those extra all your code is cleanup
> >
> > johan
> >
> > On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]>
> wrote:
> >
> >> Yeah, it could even be in its separate utility class:
> >>
> >> interface IModel {}
> >>
> >> class Component {
> >>private IModel model;
> >>
> >> public IModel getModel() {
> >>return model;
> >>}
> >> }
> >>
> >> public class Unsafe {
> >>public static IModel cast(IModel model) {
> >> return (IModel) model;
> >>}
> >> }
> >>
> >> class MyComp extends Component {
> >>public MyComp() {
> >> IModel model = Unsafe.cast(getModel());
> >>}
> >> }
> >>
> >> I'm merely pointing out that there exists a solution to do unsafe cast
> >> without getting compiler warning. Just like normal casts are handled.
> >>
> >> I don't think Johan's all or nothing proposition is very pragmatic one.
> >> Without generic IModel we do not get any API discoverability and our
> >> APIs continue to suck. For instance, how can API user know what kind of
> >> model this needs: MyJuicyComponent(String id, IModel model). At one
> >> point we did this: MyJuicyComponent(String id, IModel/**/
> >> model) but this convention is far from optimal. To be sure, one needs to
> >> browse the sources...
> >>
> >> Joni
> >>
> >> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
> >> > Well, maybe it really is a hack that's too ugly. We might have two
> >> methods,
> >> >
> >> > default getModel() that doesn't cast it and alternative convenience
> >> > one that does.
> >> >
> >> > -Matej
> >> >
> >> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]>
> >> wrote:
> >> > > class Component {
> >> > > private IModel model;
> >> > >
> >> > > public IModel getModel() {
> >> > > return (IModel) model;
> >> > > }
> >> > > }
> >> > >
> >> > > I like this. Even with the possible class cast exception. Because
> >> > > without generics, it doesn't leave you no other option than to cast
> it
> >> > > to your model, which isn't much better either, as you get the same
> >> > > result except that it looks uglier.
> >> > >
> >> > > -Matej
> >> > >
> >> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
> >> [EMAIL PROTECTED]> wrote:
> >> > >> no i am really against that falls IModel getModel() method
> >> > >> that really abuses everything that generics stands for. For such a
> >> basic
> >> > >> thing.
> >> > >> this is really bad programming
> >> > >> If we drop it we also pretty much drop it from IModel or have
> warnings
> >> in
> >> > >> the user code.
> >> > >>
> >> > >> But then drop it completely is better because then we have to do a
> >> cast and
> >> > >> you really think about that
> >> > >> Not having that fake assurance..
> >> > >>
> >> > >> johan
> >> > >>
> >> > >>
> >> > >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
> >> > >> [EMAIL PROTECTED]> wrote:
> >> > >>
> >> > >>> Befor
Re: Quick question regarding TabbedPanel and forms
Overriding newLink() was the key. However, rather than using a
SubmitLink, I decided to bypass the whole issue entirely by simply
disabling the currently selected link. In my page's constructor, I
added the following code:
TabbedPanel tabbedPanel = new TabbedPanel("tabs", tabs) {
@Override
protected WebMarkupContainer newLink(String linkId, final
int index) {
Link link = new Link(linkId) {
private static final long serialVersionUID = 1L;
@Override
public void onClick() {
setSelectedTab(index);
}
};
link.setEnabled(getSelectedTab() != index);
return link;
}
};
tabbedPanel.setSelectedTab(0);
add(tabbedPanel);
A couple of minor CSS tweaks were needed so the tabs would display
correctly since the disabled link turns into a instead.
Anyway, it works like a charm.
Just a suggestion...It would be great if TabbedPanel had a boolean
method called, for example, wantsDisabledSelectedTab() which could be
easily overridden to provide this behavior for us; the default
implementation of newLink() could incorporate this check and disable
the selected tab appropriately.
Thanks,
Justin
On May 21, 2008, at 10:43 PM, Igor Vaynberg wrote:
you can override tabbedpanel.newlink and return a submitlink
instead.that way the form has to be submitted/validated before tabs
can be switched.
-igor
On Wed, May 21, 2008 at 9:51 PM, Justin Morgan - Logic Sector
<[EMAIL PROTECTED]> wrote:
Hi all,
I'm running into an issue with my TabbedPanel. Currently I have a
TabbedPanel containing two tabs. Each tab panel contains a form.
Here's my
problem scenario:
1. User clicks on a tab to view it (which is really just a link
with fancy
CSS styling)
2. User enters text in that tab's form
3. Without submitting the form via submit button, the user clicks
the tab
again
4. User loses everything typed in the form (DOH!)
The problem occurs because the user clicked on a link which didn't
submit
the form, and so the form contents were lost.
My question is: Is there any way to configure a TabbedPanel to
*not* make a
live link for the currently selected tab?
Thanks for any help,
Justin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat discards content-type with StringRequestTarget
You could implement your own dynamic web resource. eg for a kml page on our
site:
public class KMLResource extends DynamicWebResource
{
Document kml;
public KMLResource(Document kml)
{
this.kml = kml;
}
@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new
ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}
class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return "application/vnd.google-earth.kml+xml";
}
private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
@Override
public int getLength()
{
return data.length;
}
}
}
then use it like this in your page
final KMLResource kmlResource = new KMLResource(kml);
getRequestCycle().setRequestTarget(new IRequestTarget() {
public void detach(RequestCycle requestCycle) {
}
public void respond(RequestCycle requestCycle) {
ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName("name");
getRequestCycle().setRequestTarget(target);
}
});
just alter it for text rather than a Document
--
View this message in context:
http://www.nabble.com/Tomcat-discards-content-type-with-StringRequestTarget-tp17380397p17399964.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: AjaxLink not clickable in IE
I have found ie to be rubbish it comes to javascript, any error in any file
can stop all the javascript on the page working. make sure you dont have
other javascript on the page which causes problems.
Also open up the wicket ajax debug window and see you anything happens in
there when you click on the link.
richard
igor.vaynberg wrote:
>
> wow. we spoil our users too much when they complain about not getting
> a response after 3 hours...
>
> -igor
>
> On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle <[EMAIL PROTECTED]>
> wrote:
>> Anyone? Or are we only talking generics today? ;-)
>>
>> Seriously, could use a 2nd pair of eyes on this one... any input
>> appreciated.
>>
>> -Original Message-
>> From: Michael Mehrle [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, May 21, 2008 2:31 PM
>> To: users@wicket.apache.org
>> Subject: AjaxLink not clickable in IE
>>
>> I've got this AjaxLink:
>>
>>
>>
>> fooLink = new AjaxLink("fooLink") {
>>
>>@Override
>>
>>public void
>> onClick(AjaxRequestTarget target) {
>>
>>Boolean
>> selected = (Boolean) fooCheckBox.getModelObject();
>>
>>if
>> (!selected) {
>>
>>
>> fooCheckBox.setModelObject((new Boolean(true)));
>>
>>}
>>
>>
>> target.addComponent(fooCheckBox);
>>
>>// pop up
>> the modal
>>
>>
>> showRecurringFooModal(recurringFooModalWindow, target);
>>
>>}
>>
>>};
>>
>>
>>
>> > key="fooLabel" />
>>
>>
>>
>> Works fine in Safari and Firefox but in IE it's not clickable - looks
>> like a link but the mouse pointer doesn't change and nothing happens
>> when clicking. No error message either in IE's JS console or in AJAX.
>> Any idea what I'm doing wrong here?
>>
>>
>>
>> Michael
>>
>>
>> -
>> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/AjaxLink-not-clickable-in-IE-tp17379705p17399591.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: (Class>) casting troubles
Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...
-Matej
On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> I would all be easier if getModel() and getModelObject() weren't
> final. (I know there's a reason why they are, I'm not questioning it).
>
> Then in your component subclass you coud do IModel getModel()
> { return (IModel)super.getModel() }, similiar with
> getmodelobject so you wouldn't have casts all over places and it would
> be safer too).
>
> -Matej
>
> On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> It isnt all or nothing.. i never said that
>>
>> I just say if you dont want Component but you do want IModel
>> then you will get a warning at getModel()
>> we as a framework shouldnt hide the warning at that call.
>>
>> But i am also curious how many people get really the model back from a
>> component (not counting specific places like repeaters.onpopuplate)
>>
>> because i think most people do component.getModelObject() which then needs a
>> cast
>>
>> But i like that extra helper method way more then having an extra
>> getUnsafeModel() method..
>> because thats explicit a developer has to really choose for it.
>>
>> i think there are 3 options
>>
>> 1> keep it what we have now, tweak it with the feedback we get from 1.4M2
>> 2> drop it on Component only and have a class like you described above to do
>> this: IModel model = Unsafe.cast(component.getModel()); (its still
>> a hack and a sense of false security but ok. if people really want this..)
>> 3> drop it on Component and Model
>>
>>
>> i am +1 on 1
>> and -0 on 2 and 3
>>
>> I still think it is not bad. and you can come around it really easy by just
>> creating a few extra classes like
>>
>> StringLabel
>> NumberLabel
>> StringTextField
>> NumberTextField
>>
>> if you only have a few of those extra all your code is cleanup
>>
>> johan
>>
>> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]> wrote:
>>
>>> Yeah, it could even be in its separate utility class:
>>>
>>> interface IModel {}
>>>
>>> class Component {
>>>private IModel model;
>>>
>>> public IModel getModel() {
>>>return model;
>>>}
>>> }
>>>
>>> public class Unsafe {
>>>public static IModel cast(IModel model) {
>>> return (IModel) model;
>>>}
>>> }
>>>
>>> class MyComp extends Component {
>>>public MyComp() {
>>> IModel model = Unsafe.cast(getModel());
>>>}
>>> }
>>>
>>> I'm merely pointing out that there exists a solution to do unsafe cast
>>> without getting compiler warning. Just like normal casts are handled.
>>>
>>> I don't think Johan's all or nothing proposition is very pragmatic one.
>>> Without generic IModel we do not get any API discoverability and our
>>> APIs continue to suck. For instance, how can API user know what kind of
>>> model this needs: MyJuicyComponent(String id, IModel model). At one
>>> point we did this: MyJuicyComponent(String id, IModel/**/
>>> model) but this convention is far from optimal. To be sure, one needs to
>>> browse the sources...
>>>
>>> Joni
>>>
>>> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
>>> > Well, maybe it really is a hack that's too ugly. We might have two
>>> methods,
>>> >
>>> > default getModel() that doesn't cast it and alternative convenience
>>> > one that does.
>>> >
>>> > -Matej
>>> >
>>> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]>
>>> wrote:
>>> > > class Component {
>>> > > private IModel model;
>>> > >
>>> > > public IModel getModel() {
>>> > > return (IModel) model;
>>> > > }
>>> > > }
>>> > >
>>> > > I like this. Even with the possible class cast exception. Because
>>> > > without generics, it doesn't leave you no other option than to cast it
>>> > > to your model, which isn't much better either, as you get the same
>>> > > result except that it looks uglier.
>>> > >
>>> > > -Matej
>>> > >
>>> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
>>> [EMAIL PROTECTED]> wrote:
>>> > >> no i am really against that falls IModel getModel() method
>>> > >> that really abuses everything that generics stands for. For such a
>>> basic
>>> > >> thing.
>>> > >> this is really bad programming
>>> > >> If we drop it we also pretty much drop it from IModel or have warnings
>>> in
>>> > >> the user code.
>>> > >>
>>> > >> But then drop it completely is better because then we have to do a
>>> cast and
>>> > >> you really think about that
>>> > >> Not having that fake assurance..
>>> > >>
>>> > >> johan
>>> > >>
>>> > >>
>>> > >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
>>> > >> [EMAIL PROTECTED]> wrote:
>>> > >>
>>> > >>> Before we do a vote I want to make sure what our alternatives are.
>>> > >>>
>>> > >>> I still like Joni's alternative. I don't think they are an
>>> > >>> abomination,
Re: (Class>) casting troubles
I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not questioning it).
Then in your component subclass you coud do IModel getModel()
{ return (IModel)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it would
be safer too).
-Matej
On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> It isnt all or nothing.. i never said that
>
> I just say if you dont want Component but you do want IModel
> then you will get a warning at getModel()
> we as a framework shouldnt hide the warning at that call.
>
> But i am also curious how many people get really the model back from a
> component (not counting specific places like repeaters.onpopuplate)
>
> because i think most people do component.getModelObject() which then needs a
> cast
>
> But i like that extra helper method way more then having an extra
> getUnsafeModel() method..
> because thats explicit a developer has to really choose for it.
>
> i think there are 3 options
>
> 1> keep it what we have now, tweak it with the feedback we get from 1.4M2
> 2> drop it on Component only and have a class like you described above to do
> this: IModel model = Unsafe.cast(component.getModel()); (its still
> a hack and a sense of false security but ok. if people really want this..)
> 3> drop it on Component and Model
>
>
> i am +1 on 1
> and -0 on 2 and 3
>
> I still think it is not bad. and you can come around it really easy by just
> creating a few extra classes like
>
> StringLabel
> NumberLabel
> StringTextField
> NumberTextField
>
> if you only have a few of those extra all your code is cleanup
>
> johan
>
> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]> wrote:
>
>> Yeah, it could even be in its separate utility class:
>>
>> interface IModel {}
>>
>> class Component {
>>private IModel model;
>>
>> public IModel getModel() {
>>return model;
>>}
>> }
>>
>> public class Unsafe {
>>public static IModel cast(IModel model) {
>> return (IModel) model;
>>}
>> }
>>
>> class MyComp extends Component {
>>public MyComp() {
>> IModel model = Unsafe.cast(getModel());
>>}
>> }
>>
>> I'm merely pointing out that there exists a solution to do unsafe cast
>> without getting compiler warning. Just like normal casts are handled.
>>
>> I don't think Johan's all or nothing proposition is very pragmatic one.
>> Without generic IModel we do not get any API discoverability and our
>> APIs continue to suck. For instance, how can API user know what kind of
>> model this needs: MyJuicyComponent(String id, IModel model). At one
>> point we did this: MyJuicyComponent(String id, IModel/**/
>> model) but this convention is far from optimal. To be sure, one needs to
>> browse the sources...
>>
>> Joni
>>
>> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
>> > Well, maybe it really is a hack that's too ugly. We might have two
>> methods,
>> >
>> > default getModel() that doesn't cast it and alternative convenience
>> > one that does.
>> >
>> > -Matej
>> >
>> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]>
>> wrote:
>> > > class Component {
>> > > private IModel model;
>> > >
>> > > public IModel getModel() {
>> > > return (IModel) model;
>> > > }
>> > > }
>> > >
>> > > I like this. Even with the possible class cast exception. Because
>> > > without generics, it doesn't leave you no other option than to cast it
>> > > to your model, which isn't much better either, as you get the same
>> > > result except that it looks uglier.
>> > >
>> > > -Matej
>> > >
>> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
>> [EMAIL PROTECTED]> wrote:
>> > >> no i am really against that falls IModel getModel() method
>> > >> that really abuses everything that generics stands for. For such a
>> basic
>> > >> thing.
>> > >> this is really bad programming
>> > >> If we drop it we also pretty much drop it from IModel or have warnings
>> in
>> > >> the user code.
>> > >>
>> > >> But then drop it completely is better because then we have to do a
>> cast and
>> > >> you really think about that
>> > >> Not having that fake assurance..
>> > >>
>> > >> johan
>> > >>
>> > >>
>> > >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
>> > >> [EMAIL PROTECTED]> wrote:
>> > >>
>> > >>> Before we do a vote I want to make sure what our alternatives are.
>> > >>>
>> > >>> I still like Joni's alternative. I don't think they are an
>> > >>> abomination, because the /potential/ class cast exception you get is
>> > >>> the same as with current 1.3. But the benefit of documenting the
>> model
>> > >>> parameters in DDC, LV, etc. is HUGE.
>> > >>>
>> > >>> I really appreciate the time and effort that went into implementing
>> > >>> the generification. But I also see what kind of mess this brought and
>> > >>> I really don't like the Component generification part.
>> > >>>
>>
Re: localization properties file
thanks :) On Thu, May 22, 2008 at 10:25 AM, Gwyn Evans <[EMAIL PROTECTED]> wrote: > See http://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html for > more options > > On Thu, May 22, 2008 at 8:05 AM, Maurice Marrink <[EMAIL PROTECTED]> > wrote: > > That would be the easiest yes. > > > > Maurice > > > > On Thu, May 22, 2008 at 7:45 AM, Eyal Golan <[EMAIL PROTECTED]> wrote: > >> Hi, > >> If I want a centralized properties file for localization, where should I > put > >> it and how should I call it? > >> Is it supposed to be in the same folder as my WebApplication class? > >> Is is supposed to have the same name as this class (with extension > >> properties)? > >> > >> Thanks > >> > >> -- > >> Eyal Golan > >> [EMAIL PROTECTED] > >> > >> Visit: http://jvdrums.sourceforge.net/ > >> > > > > - > > 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] > > -- Eyal Golan [EMAIL PROTECTED] Visit: http://jvdrums.sourceforge.net/
Re: (Class>) casting troubles
It isnt all or nothing.. i never said that
I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.
But i am also curious how many people get really the model back from a
component (not counting specific places like repeaters.onpopuplate)
because i think most people do component.getModelObject() which then needs a
cast
But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.
i think there are 3 options
1> keep it what we have now, tweak it with the feedback we get from 1.4M2
2> drop it on Component only and have a class like you described above to do
this: IModel model = Unsafe.cast(component.getModel()); (its still
a hack and a sense of false security but ok. if people really want this..)
3> drop it on Component and Model
i am +1 on 1
and -0 on 2 and 3
I still think it is not bad. and you can come around it really easy by just
creating a few extra classes like
StringLabel
NumberLabel
StringTextField
NumberTextField
if you only have a few of those extra all your code is cleanup
johan
On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]> wrote:
> Yeah, it could even be in its separate utility class:
>
> interface IModel {}
>
> class Component {
>private IModel model;
>
> public IModel getModel() {
>return model;
>}
> }
>
> public class Unsafe {
>public static IModel cast(IModel model) {
> return (IModel) model;
>}
> }
>
> class MyComp extends Component {
>public MyComp() {
> IModel model = Unsafe.cast(getModel());
>}
> }
>
> I'm merely pointing out that there exists a solution to do unsafe cast
> without getting compiler warning. Just like normal casts are handled.
>
> I don't think Johan's all or nothing proposition is very pragmatic one.
> Without generic IModel we do not get any API discoverability and our
> APIs continue to suck. For instance, how can API user know what kind of
> model this needs: MyJuicyComponent(String id, IModel model). At one
> point we did this: MyJuicyComponent(String id, IModel/**/
> model) but this convention is far from optimal. To be sure, one needs to
> browse the sources...
>
> Joni
>
> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
> > Well, maybe it really is a hack that's too ugly. We might have two
> methods,
> >
> > default getModel() that doesn't cast it and alternative convenience
> > one that does.
> >
> > -Matej
> >
> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]>
> wrote:
> > > class Component {
> > > private IModel model;
> > >
> > > public IModel getModel() {
> > > return (IModel) model;
> > > }
> > > }
> > >
> > > I like this. Even with the possible class cast exception. Because
> > > without generics, it doesn't leave you no other option than to cast it
> > > to your model, which isn't much better either, as you get the same
> > > result except that it looks uglier.
> > >
> > > -Matej
> > >
> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
> [EMAIL PROTECTED]> wrote:
> > >> no i am really against that falls IModel getModel() method
> > >> that really abuses everything that generics stands for. For such a
> basic
> > >> thing.
> > >> this is really bad programming
> > >> If we drop it we also pretty much drop it from IModel or have warnings
> in
> > >> the user code.
> > >>
> > >> But then drop it completely is better because then we have to do a
> cast and
> > >> you really think about that
> > >> Not having that fake assurance..
> > >>
> > >> johan
> > >>
> > >>
> > >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
> > >> [EMAIL PROTECTED]> wrote:
> > >>
> > >>> Before we do a vote I want to make sure what our alternatives are.
> > >>>
> > >>> I still like Joni's alternative. I don't think they are an
> > >>> abomination, because the /potential/ class cast exception you get is
> > >>> the same as with current 1.3. But the benefit of documenting the
> model
> > >>> parameters in DDC, LV, etc. is HUGE.
> > >>>
> > >>> I really appreciate the time and effort that went into implementing
> > >>> the generification. But I also see what kind of mess this brought and
> > >>> I really don't like the Component generification part.
> > >>>
> > >>> Martijn
> > >>>
> > >>> On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg <
> [EMAIL PROTECTED]>
> > >>> wrote:
> > >>> > ok so we pretty much have some core people wanting to back out the
> > >>> > generics support.
> > >>> >
> > >>> > shall we start a vote? johan, gerolf and i have spent a ridiculous
> > >>> > amount of time trying to generify the codebase and remove all the
> > >>> > shitty warnings. if there is even a slight chance of this getting
> > >>> > backed out i do not want to spend any more time on this until the
> > >>> > issue is resolved.
> > >>> >
> > >>> > also
Re: localization properties file
See http://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html for more options On Thu, May 22, 2008 at 8:05 AM, Maurice Marrink <[EMAIL PROTECTED]> wrote: > That would be the easiest yes. > > Maurice > > On Thu, May 22, 2008 at 7:45 AM, Eyal Golan <[EMAIL PROTECTED]> wrote: >> Hi, >> If I want a centralized properties file for localization, where should I put >> it and how should I call it? >> Is it supposed to be in the same folder as my WebApplication class? >> Is is supposed to have the same name as this class (with extension >> properties)? >> >> Thanks >> >> -- >> Eyal Golan >> [EMAIL PROTECTED] >> >> Visit: http://jvdrums.sourceforge.net/ >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class>) casting troubles
Yeah, it could even be in its separate utility class:
interface IModel {}
class Component {
private IModel model;
public IModel getModel() {
return model;
}
}
public class Unsafe {
public static IModel cast(IModel model) {
return (IModel) model;
}
}
class MyComp extends Component {
public MyComp() {
IModel model = Unsafe.cast(getModel());
}
}
I'm merely pointing out that there exists a solution to do unsafe cast
without getting compiler warning. Just like normal casts are handled.
I don't think Johan's all or nothing proposition is very pragmatic one.
Without generic IModel we do not get any API discoverability and our
APIs continue to suck. For instance, how can API user know what kind of
model this needs: MyJuicyComponent(String id, IModel model). At one
point we did this: MyJuicyComponent(String id, IModel/**/
model) but this convention is far from optimal. To be sure, one needs to
browse the sources...
Joni
On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
> Well, maybe it really is a hack that's too ugly. We might have two methods,
>
> default getModel() that doesn't cast it and alternative convenience
> one that does.
>
> -Matej
>
> On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > class Component {
> > private IModel model;
> >
> > public IModel getModel() {
> > return (IModel) model;
> > }
> > }
> >
> > I like this. Even with the possible class cast exception. Because
> > without generics, it doesn't leave you no other option than to cast it
> > to your model, which isn't much better either, as you get the same
> > result except that it looks uglier.
> >
> > -Matej
> >
> > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >> no i am really against that falls IModel getModel() method
> >> that really abuses everything that generics stands for. For such a basic
> >> thing.
> >> this is really bad programming
> >> If we drop it we also pretty much drop it from IModel or have warnings in
> >> the user code.
> >>
> >> But then drop it completely is better because then we have to do a cast and
> >> you really think about that
> >> Not having that fake assurance..
> >>
> >> johan
> >>
> >>
> >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
> >> [EMAIL PROTECTED]> wrote:
> >>
> >>> Before we do a vote I want to make sure what our alternatives are.
> >>>
> >>> I still like Joni's alternative. I don't think they are an
> >>> abomination, because the /potential/ class cast exception you get is
> >>> the same as with current 1.3. But the benefit of documenting the model
> >>> parameters in DDC, LV, etc. is HUGE.
> >>>
> >>> I really appreciate the time and effort that went into implementing
> >>> the generification. But I also see what kind of mess this brought and
> >>> I really don't like the Component generification part.
> >>>
> >>> Martijn
> >>>
> >>> On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg <[EMAIL PROTECTED]>
> >>> wrote:
> >>> > ok so we pretty much have some core people wanting to back out the
> >>> > generics support.
> >>> >
> >>> > shall we start a vote? johan, gerolf and i have spent a ridiculous
> >>> > amount of time trying to generify the codebase and remove all the
> >>> > shitty warnings. if there is even a slight chance of this getting
> >>> > backed out i do not want to spend any more time on this until the
> >>> > issue is resolved.
> >>> >
> >>> > also we should halt m2 until this is resolved.
> >>> >
> >>> > personally i do not mind backing out generics, they turned out to be
> >>> > quiet a disappointment for me as well, but my feelings about this are
> >>> > not strong.
> >>> >
> >>> > we can still use generics such as setresponsepage(class >>> > page>) to gain bits of typesafety here and there, but if we remove
> >>> > them from component we obviously have to remove them from imodel.
> >>> >
> >>> > so lets start a vote with a parallel discussion thread just for this.
> >>> >
> >>> > -igor
> >>> >
> >>> > On Wed, May 21, 2008 at 8:19 AM, Martijn Dashorst
> >>> > <[EMAIL PROTECTED]> wrote:
> >>> >> On Wed, May 21, 2008 at 5:05 PM, Johan Compagner <[EMAIL PROTECTED]>
> >>> wrote:
> >>> >>> Generics is type safety
> >>> >>
> >>> >> I didn't say generics isn't type safety. But APPLYING generics for the
> >>> >> Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less
> >>> >> questions on the mailing list regarding DDC, ListView, etc. is the
> >>> >> main goal for applying generics in Wicket.
> >>> >>
> >>> >>> I am against this abuse big time -1000 from me
> >>> >>
> >>> >> I'm -1000^1 for abusing my eyes and brain in
> >>> >> the way it currently is implemented in Wicket. It is completely and
> >>> >> utterly unusable for beginners. There is no way this is going to make
> >>> >> the number of questions on the mailinglist less (other than by scaring
> >>> >> away anyone that wants to
Re: localization properties file
That would be the easiest yes. Maurice On Thu, May 22, 2008 at 7:45 AM, Eyal Golan <[EMAIL PROTECTED]> wrote: > Hi, > If I want a centralized properties file for localization, where should I put > it and how should I call it? > Is it supposed to be in the same folder as my WebApplication class? > Is is supposed to have the same name as this class (with extension > properties)? > > Thanks > > -- > Eyal Golan > [EMAIL PROTECTED] > > Visit: http://jvdrums.sourceforge.net/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
