But then do enlight me. Why did we first need to have the PageParameter constructor of all homepages?
Because currently they don't make any sense. Because there is nothing of value in it anyway. And a user can't control in any way what can be put in.
I already fixed this, so that we don't have to have a PageParameter constructor. But still what is the use of those if we can't use/set them??
And i don't agree that it is a partucular usecase.... Why should it? Again why do we have those pageparameters?
Another question: Why can i set those in wicket for every page but not for the homepage?
johan
Jonathan Locke wrote:
my problem with addressing this particular use case is that wicket's prime goal is to be dirt simple. the assumption in wicket is that a web application has a single, bookmarkable home page which takes no meaningful parameters. as far as i'm concerned, that's the very definition of a home page. this is good because it's simple and based on what users expect and intuit from their usage of web browsers.
i can totally see what you're talking about, johan, but your particular use case conflicts conceptually with how home pages were designed and i'd like to see more evidence of the problem (and in all probability a host of related problems) from other users and then spend some time discussing different solutions before we address this pluggability issue.
no offense intended, but i'd like to see us simply delay this feature to 1.1 so we can spend more time thinking about the problem you're solving and any /related/ use cases that might crop up. for example, it may turn out that this problem of controlling home page construction has some other use case of which we are not yet aware and it would be much better to make the factory apparatus more extensible where home pages are concerned. it would be nice to have a few months for issues to occur so we can solve the most problems with the least and simplest code. the one thing that might be worth looking into now is whether we've designed the page factory code in a way that wouldn't prevent it from being made more flexible in the future. (i'm talking off the top of my head here, btw...).
does my concern make sense? i'm only asking that we delay this feature so we have time to think it through together.
jon
Johan Compagner wrote:
The map is converted to PageParameters. Previous a home page was always constructed with empty PageParameters (or what the request just happens to have in that example) Now the map's values are also inserted into the page parameters and then the homepage is constructed with those.
ALL the pages you construct after the HomePage can be constructed
with youre own PageParameters see IPageFactory.newPage() methods.
Why can't i do the same with the homepage???
Why shouldn't we be able to do the same thing as we would do with all the pages that are
constructed after the homepage?
It is just very easy to have. No more special subclasses as Juergen has.
I hate cast every where in the code.. I have seen this so often that i call a method from
a framework and suddenly i get a classcast exception because they are trying to cast it
somewhere deep in the code because they expect something else.
I stumbled on the usecase because i had to implement a application that is completely
made of a plugins. And the core (that has the basic things like a homepage) plugin needs
to be configured from another web plugin.
So there i set the homepage of the core and i want to configure somethings for that homepage
So the most logical thing is to use PageParameters for that..
johan
Jonathan Locke wrote:
i think i'm only partly getting what each of you are saying.
i think i'm -1 on this change, but i'd like to understand johan's reasoning first...
i don't really see the implementation details of home page construction as something that belongs in application settings. can you explain why it is that you want to put these values in app settings? is there some reason why these values can't be set in your home page's constructor? and if you're trying to make your home page xml-configurable, why not just use the Xml class to do that in your home page's constructor?
btw, i haven't really looked at the source code, but the home page really
should take PageParameters still even though they aren't used because
the page is bookmarkable.
Johan Compagner wrote:
Where does that getHomePageDefaults come from?
IApplication doesn't have this method.
So it is an implementation of youre own? That you have to Cast to?
That is not what i want. The Page can be used by Any application i want
Then there shouldn't be any dependencies on an implementation if IApplication!
johan
Juergen Donnerstag wrote:
As I've already written. Clean simple, no uncessary changes to the core.
class MyPage extends Page { public MyPage() {
param = ((MyApplication)getApplication()).getHomePageDefaults();
}
Juergen
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
