you may have a point here. it's not that there's /nothing/ of value in it. but you might argue there is very little value.
the reason i made home pages take PageParameters was conceptual simplicity. it could be that it would make more sense, as you point out, for home pages to be special bookmarkable pages that take no parameters. i'm not sure that would be bad. but the original idea was that /all/ bookmarkable pages in wicket can be immediately identified by the user by looking for this constructor parameter. if you don't have this pattern, the user has to look at the class name or the application settings to discover that the class is a home page and that's why it's bookmarkable but doesn't take PageParameters. arguably, with one less thing to know, the surface area of the API decreases from the user's perspective. a subtle point, perhaps. also, with an inconsistency here, all URLs that link back to the home page would no longer have the hint in the URL that the page is bookmarkable. this could be remedied with a special case if we decided to remove PageParameters from home page constructors.
for some background, this ended up this way because there was a point in the project (before i gave it to anyone) where i thought about having page parameters set separately through an IBookmarkable interface (in passing, it would be interesting if constructor signatures could be somehow be enforced by some interface-/like/ specification...) so that bookmarkable pages would be typesafe and even more easily identified... we could conceivably re-examine that, but there are some downsides to the semantics of two-phase construction and it's convenient and straightforward to have page parameters available in the constructor. i went to considerable trouble to make that happen if you look at the code. if you have setPageParameters, you wind up needing init() and runtime checks / problems... but there's still something appealing about IBookmarkable which i was trying to emulate by making the constructors have the same signature.
more deeply, i've begun lately to wonder if the implementation of Java (and C++) constructors isn't a mistake of sorts because of all the boundary conditions, ambiguity, lack of properties, lack of interface typing, etc. on the flip side you've got all the ugly semantics issues with two-phase construction. what i'm wondering is if it might not be better in some distant future langauge to have a compromise that does away with both to some degree by creating a kind of "mechnically enforced two-phase construction". basically, you'd set up rules for proper initialization by specifying preconditions in terms of methods that must be (successfully) called and their order of invocation (if any) before the object's init block is called (automatically) and the object is considered fully ready for use (and other methods can be called). then you don't have any of the problems with parameterized constructors because you don't have them. and there isn't this ugly choice to make between constructors and two-phase construction where people spend half their time trying to guess which is better usage. an object in this future language would /always/ be "initialized" in a sense because there is only memory allocation and no construction (until the precoditions are satisfied and the init block executes), has convenient beans properties for everything by definition and the VM can mechanically determine if the user constructed the object correctly (at compile time and/or runtime). okay, i'm rambling. i also suspect i might be right. ;-)
jon
Johan Compagner wrote:
Ok i can revert it back
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
-------------------------------------------------------
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
