Re: VOTE: Remove ? extends from constructor of DropDownChoice
Hi everyone (I'm new to the list),
Johannes, you are right about lists:
> If the constructor accepts the widened type, you can add all those
> lists...
>
> List n = new List;
> List n = new List;
> List n = new List;
But in our case the constructor parameter is an IModel, no a list. Try
the following:
IModel> model = new
LoadableDetachableModel>() { ... };
See my comment in JIRA for more detail.
Olivier
2009/3/4 Johannes Schneider :
> On Wed, 2009-03-04 at 10:04 -0500, Brill Pappin wrote:
>> I actually wasn't saying they were the same.
>> What I said (meant) was that:
>>
>> a) don't lock down
>
> Locking down means *removing* the wildcard. Adding the wildcard *widens*
> the collection.
>
> To be clear:
> Wildcard --> it fits for everybody
> No wildcard --> it fits only for some special cases (maybe yours)
>
>> b) I prefer the explicit form rather than the "Any of type" form. i.e.
>> > rather than >.
>
> They mean something completely different. I understand that you prefer
> the shorter version. Many do. But it stays wrong...
>
> If the constructor accepts "List", everybody *has* to give you
> exactly a List.
>
> List n = new List;
>
>
> If the constructor accepts the widened type, you can add all those
> lists...
>
> List n = new List;
> List n = new List;
> List n = new List;
>
>
> If you don't believe me, take a look at GlazedLists. Compare version 1.7
> and version 1.8. They changed exactly that thing (a non backward
> compatible change!). They made exactly the same fault...
>
>
> Regards,
>
> Johannes
>
>>
>> - Brill
>>
>> On 4-Mar-09, at 6:26 AM, Johannes Schneider wrote:
>>
>> > On Tue, 2009-03-03 at 16:02 -0500, Brill Pappin wrote:
>> >> I'd hate to be
>> >> prevented from doing so simply because someone wanted to lock down an
>> >> API that didn't really need locking down.
>> >
>> > You are wrong. *Widening* a collection is the exact opposite of
>> > "locking
>> > down".
>> > If you want to have some fancy (read "hacky") write access to the
>> > model
>> > you are free to simply cast...
>> > That is the right choice here. You know that you have a special
>> > model in
>> > there, so cast it.
>> >
>> > But the "common" case is, that you don't know for sure whether the
>> > model
>> > supports adding of choices or not.
>> >
>> >
>> > If you don't believe me, take a look at JComboBox.
>> > javax.swing.JComboBox#getModel returns a *read only* view of the
>> > model.
>> >
>> >
>> >
>> > Regards,
>> >
>> > Johannes
>> >
>> >
>> >> I think the syntax doesn't really mean read only, and if the wicket
>> >> developers really want it to be read only, wrapping the list would be
>> >> the way to go.
>> >>
>> >> I'm for the plain old > because its simple and explicit...
>> >> > would be my next choice because it widens the
>> >> scope.
>> >>
>> >> - Brill
>> >>
>> >> On 2-Mar-09, at 3:44 PM, James Carman wrote:
>> >>
>> >>> Aren't both the "choices" model in DDC and the actual model of
>> >>> ListView supposed to be considered read-only (as far as the
>> >>> component
>> >>> is concerned)? The DDC and ListView don't need to be able to alter
>> >>> those models anyway, right? Perhaps my experience is just too
>> >>> limited, but I don't think I've ever tried to do either one of your
>> >>> usecases (I always consider them read-only).
>> >>>
>> >>>
>> >>> On Mon, Mar 2, 2009 at 3:24 PM, Igor Vaynberg
>> >>> wrote:
>> see WICKET-2126
>>
>> -igor
>>
>> On Mon, Mar 2, 2009 at 12:19 PM, James Carman
>> wrote:
>> > I vote -0.99 on this (non-binding of course). I'd vote +1 to
>> > making
>> > ListView accept List rather than making DDC less
>> > flexible.
>> >
>> > On Mon, Mar 2, 2009 at 3:11 PM, Brill Pappin
>> > wrote:
>> >> Ok, as suggested, here is the thread, and the first vote.
>> >>
>> >> +1
>> >> for making the generic definition the same for all list type
>> >> components.
>> >>
>> >> FYI - you can also "vote" in the issue I just created at (which
>> >> might
>> >> actually be a better place to vote):
>> >> https://issues.apache.org/jira/browse/WICKET-2137
>> >>
>> >> - Brill
>> >>
>> >>
>> >>
>> >>
>> >> On 28-Feb-09, at 5:18 PM, Jeremy Thomerson wrote:
>> >>
>> >>> Perhaps start a vote thread, with the subject something like:
>> >>> "VOTE:
>> >>> Remove
>> >>> ? extends from constructor of DropDownChoice".
>> >>>
>> >>> I'd be +1 non-binding
>> >>>
>> >>>
>> >>> --
>> >>> Jeremy Thomerson
>> >>> http://www.wickettraining.com
>> >>>
>> >>>
>> >>> On Sat, Feb 28, 2009 at 3:33 PM, Brill Pappin
>> >>> wrote:
>> >>>
>> I'm of the don't widen it camp anyway :)
>>
>> So how do I go about gathering support for having the
>> DropDownChoice work
>> with the models the way everything else does?
>>
>> - Brill
>>
>>
>> On 28
Re: Generics question
This looks exactly like the DropDownChoice issue that has been debated
recently. See the comments in JIRA:
https://issues.apache.org/jira/browse/WICKET-2137
The problem is that IModel> doesn't work
as we intuitively expect it to. It won't match IModel>
(nor IModel> for that matter).
As suggested by James, the correct generic type to achieve what you
want to do would be: IModel>
Olivier
2009/3/13 Linda van der Pal :
> This is not really Wicket related, but I don't quite know where else to ask
> this. The question is: why won't this compile?
>
> // I define a model
> IModel> subgenreModel = new
> AbstractReadOnlyModel>() {
> ...
> }
>
> // Here I try to use the model
> FieldSwitchPanel subgenrefield = *new SubgenreFieldSwitchPanel("subgenre",
> subgenreModel);*
>
>
> // This is the constructor for the class SubgenreFieldSwithcPanel
> public SubgenreFieldSwitchPanel(String id, IModel DomainObject>> choices) {
> ...
> }
>
>
> // Subgenre extends DomainObject
> public class Subgenre extends DomainObject{
> ...
> }
>
>
> The complaint is: The constructor SubgenreFieldSwitchPanel(String,
> IModel>) is undefined.
>
> Thanks,
> Linda
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: nested loop view
I think you have to add "projects" to the current category item, not
to "this" (which would refer to the categories listview itself).
So try replacing:
this.add(projects);
By:
item.add(projects);
2009/3/26 Luther Baker :
> I'm trying to create a page - similar to Jira's BROWSE PROJECTS.
>
> My initial take amounts to a loop in a loop.
>
> The outer loop is CATEGORIES and the inner loop is PROJECTS in said
> category.
>
> | CATEGORY 1
> | p1
> | p2
> | p3
>
> | CATEGORY 2
> | p4
> | p5
> | p6
>
> ...
>
> I've attached code below but if I removed the nested loop, I can easily loop
> over just CATEGORIES but as soon as I add the nested loop, it fails with the
> following
>
> WicketMessage: Error attaching this container for rendering: [Page class =
> com.fuzzybearings.milestones.web.page.user.ProjectsPage, id = 3, version =
> 0]
>
> Root cause:
>
> java.lang.IllegalArgumentException: A child with id 'projects' already
> exists:
> [MarkupContainer [Component id = categories]]
>
>
> My intuition tells me that 'wicket:id="projects"' is repeating since it is
> contained in an outer loop ... but I'm not sure how else to identify this
> type of structure in a general way. Is there a loop container more suited to
> this ... open to suggestions.
>
> Thanks in advance,
>
> -Luther
>
>
>
> *.html snippet
>
>
>
>
> wicket:id="projectLabel">[project]
>
>
>
>
>
> *.java snippet
>
> public ProjectsPage(ResourceModel bodyTitle)
> {
> super(bodyTitle);
>
> ListView categories = new ListView("categories",
> this.getCategories())
> {
>
> �...@override
> protected void populateItem(ListItem item)
> {
> Category category = (Category) item.getModelObject();
>
> ListView projects = new ListView("projects",
> ProjectsPage.this.getProjects(category))
> {
>
> �...@override
> protected void populateItem(ListItem item)
> {
> Project project = (Project) item.getModelObject();
> Link link = new Link("projectLink", item.getModel())
> {
>
> �...@override
> public void onClick() { ... }
> };
> link.add(new Label("projectLabel",
> project.getName()));
> item.add(link);
> }
> };
> this.add(projects);
> }
> };
> this.add(categories);
> }
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring integration problem
The problem is that your unit tests run out of the web container, you
can't rely on a servlet context listener to load the Spring context in
this situation.
You need a hook to inject a mock context when testing. This post
describes a solution: http://blog.ehour.nl/index.php/archives/21
2009/4/6 HHB :
> Hey,
> I'm trying to integrate Spring 2.5 into our Wicket
> application, I did the following:
>
> web.xml:
>
> contextConfigLocation
> classpath:applicationContext.xml
>
>
> org.springframework.web.
> context.ContextLoaderListener
>
>
> OpenSessionInViewFilter
> org.springframework.orm.hibernate3.
> support.OpenSessionInViewFilter
>
>
>
> WicketFilter
> org.apache.wicket.
> protocol.http.WicketFilter
>
> applicationFactoryClassName
> org.apache.wicket.spring.
> SpringWebApplicationFactory
>
>
>
> WicketFilter
> org.apache.wicket.
> protocol.http.WicketFilter
>
> applicationFactoryClassName
> org.apache.wicket.spring.
> SpringWebApplicationFactory
>
>
>
> applicationContext.xml:
>
>
>
>
> pom.xml:
>
>
> org.springframework
> spring
> 2.5.6
>
>
>
> org.apache.wicket
> wicket-spring
> 1.3.5
>
>
> org.apache.wicket
> wicket-spring-annot
> 1.3.5
>
>
> WicketApplication:
>
> @Override
> protected void init() {
> super.init();
> addComponentInstantiationListener
> (new SpringComponentInjector(this));
> }
>
> But when trying:
> mvn test
> I got the following exception:
>
> ---
> Test set: TestSuite
>
> ---
> Tests run: 2, Failures: 1, Errors: 0,
> Skipped: 1, Time elapsed: 0.498 sec <<< FAILURE!
> init(domain.TestHomePage) Time elapsed: 0 sec <<< FAILURE!
> java.lang.IllegalStateException:
> No WebApplicationContext found: no ContextLoaderListener registered?
> at org.springframework.web.context.support.
> WebApplicationContextUtils.
> getRequiredWebApplicationContext(WebApplicationContextUtils.java:70)
> at org.apache.wicket.spring.
> injection.annot.SpringComponentInjector.
> (SpringComponentInjector.java:74)
>
> Any ideas?
> Thanks.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
