You make a good point.
Is it possible to take the current property file mechanism (where you
only have to specify classes with resources) and move it into
IComponentInitializer somehow? You are right you should only be required
to specify components with resources.
Sorry, with all the emails going back and forth I lost track of what
the final property file mechanism looks like. If I remember correctly,
each component must provide a file with:
component1 = resource1, resource2, resource3
right? But I never understood, with this mechanism, how does Wicket
know which components actually end up being used by a given application
or not?
Thanks,
Gili
Igor Vaynberg wrote:
But another page is not a component - its not added to the page. So you
would have to rename getNestedComponents() to getReferencedClasses() and
that will become a hellish nightmare to maintain. In a larger app if you
have 100 pages and those can reference any other three pages...you can do
the math im sure. Now imagine maintaining that....ouch...
At least with the file approach you only need to register the classes that
actually need resource init, with your approach you would have to register
ALL classes because you are doing a recursive search.
I think what we need to do is figure out how to make the file approach work
better.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gili
Sent: Thursday, August 11, 2005 10:08 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging navigation
As I explained, all components (including Page A) must declare
public List<Class> getNestedComponents();
this replaces the external configuration file that
component developers must define and it contains roughly
similar information. The benefit of this approach, however,
is that you get compile-time errors if you reference a
nonexistant component.
So in your example, your Page would look something like this:
public class PageA extends WebPage {
public PageA() {
}
public List<Class> getNestedComponents() {
List<Class> result = new ArrayList<Class>();
result.add(PageB.class);
result.add(PageC.class);
return result;
}
public init() {
Form a=new SomeForm();
a.add(new Button() {
public void onSubmit() {
setResponsePage(new PageB());
}
add(new Link() {
public void onClick() {
setResponsePage(new PageC());
}
}
}
}
As for the second part of your question, if you add
bookmarkable pages from 3rd party libraries and they are not
reachable from any other Page, then it would be your
responsibility to add them into the Application. I would dare
say, however, that this will never occur. 3rd party libs
usually add Pages you point into, not Pages that clients hit
directly. I don't think there is a real-life use case where
this would occur but even if there was we can continue
working to automate that as well.
Gili
Igor Vaynberg wrote:
Does it make more sense now?
Ummm....not really...
How do you get PageB and PageC from the following? And what
if PageA
comes from a 3rd party lib?
public class PageA extends WebPage {
public PageA() {
Form a=new SomeForm();
a.add(new Button() {
public void onSubmit() {
setResponsePage(new PageB());
}
add(new Link() {
public void onClick() {
setResponsePage(new PageC());
}
}
}
}
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gili
Sent: Thursday, August 11, 2005 9:49 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
That's not true.
Any pages referenced from your root pages do not have
to be added. So
for example, you'd add your homepage and if it is possible to reach
all other pages from that page (recursive search) then
that's the only
page you ever need to add.
So in summary, root pages consist of all your bookmarkable pages
*minus* any bookmarkable page which can be reached from a
preexisting
root page.
So for example, if my bookmarkable pages are A, B, C
but A references
B and C (directly or indirectly), I only need to add Page A.
Does it make more sense now?
Gili
Igor Vaynberg wrote:
What do you mean by *root pages* - all pages are root pages.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gili
Sent: Thursday, August 11, 2005 9:41 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
You'd only have to register the *root* Pages. All other pages
(including bundled third party ones) are discovered for free.
Gili
Igor Vaynberg wrote:
I think it would really suck to have to register all your
pages. Also
what about pages that come bundled with a third party lib -
same problem remains.
-igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gili
Sent: Thursday, August 11, 2005 9:26 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
I suggested, multiple times now, how we can completely
eliminate the
need for these external configuration files. No one has yet
to explain
to me why this idea would not work or why it is worse than
the current
design.
Why not use this mechanism?
public interface IComponentInitializer {
public void init(Application application);
public List<Class> getNestedComponents(); }
where getNestedComponents() returns the class names of
all components
that will be added into the component. This will allow you
to discover
(recursively) all the components in a given Application.
An end-user then only has to say:
Application.add(rootPage1);
Application.add(rootPage2);
and Wicket will then automatically find out about all
the remaining
components by invoking getNestedComponents().
Finally, as I already explained, we move component
configuration
(calling add() etc...) from the constructor (where it currently
resides) into a separate method (i.e.
init()) and the default constructor for Page should do
nothing. This
way Wicket can easily construct pages, invoke
getNestedComponents() to find out all nested components
in a very
efficient manner.
Gili
Johan Compagner wrote:
I don't think you can search for that..
If you know a way then i am will check that out.
because how would you do that? How do you can through ALL
packages (==
directories)
johan
Igor Vaynberg wrote:
Yes I see Jon. Thank you for a very long and detailed
explanation as
to why
my idea sucked. I still think there is some room for
improvement in the
current situation. Cant we do a saerch through avail
packages looking
for a
.resources file (im not sure how this would be done).
It would be nice to simply have DatePicker.resources side
by side with
DatePicker.java. It would eliminate refactoring headaches
at least as
far as
the package names go and it wouldn't be sitting in some
separate folder.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of
Jonathan Locke
Sent: Thursday, August 11, 2005 1:17 AM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and
paging navigation
actually it's not just that the service registration info
has to be
put somewhere, it's that a client component that's using
a service to
create a dynamic resource like, for example, some kind of
panel that
wants a dynamic button image created...
/that component/ would have to be able to create its
images /when the
app starts/ (because of clustering and server restarts).
and /only
the panel component itself/ can or should know about this
/and/ it
has to be done on startup. wicket's resource handling
classes are
already fully featured, object-oriented "services" (but
less vague
and more OO powerful) by virtue of the fact that
they implement
the IResourceListener interface and respond to requests
for resources
(ANY resource). so i just don't see any value at all in
this service
concept beyond what we've already got. in fact, i think
it would
significantly /subtract/ from wicket's existing support
for dynamic
resources (think "service" if you prefer)... and again,
even if we
did change the world, it wouldn't solve the bootstrapping
problem we
have for components.
Johan Compagner wrote:
how does a component with a dynamically generated
image make that
image available in your scheme?
the component has to register the image with the
service, doesn't
it?
The component doesn't need to register an image with a
service, it
can register the service that creates the images.
The images themselves can be created on the first request
http://www..../app?service=mydynamicbuttons&button=A
Whenever this url is hit wicket forwards the
control to the
registered mydynamicbuttons service (registered by whatever
component) which creates the image A, caches it, and
streams it to
response. Or precreate whatever you need when the
service
object is
created and registered with the application.
And THIS last part is just the problem
how does it register itself? When?
Where is it specified that a component does that?
I think in the end we have exactly the same thing...
you have a file like:
mydynamicbuttons=my.class.that.exposes.this.Service
johan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement &
Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement &
Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects &
Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams
* Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
