It is dirty cheap because I explained in step 4 (see my list below!)
that we move all the add() operations from the constructor into a init()
method. So the constructor is guaranteed to be empty.
Gili
Johan Compagner wrote:
why should it be dirty cheap??
In youre default constructor i can fill my models.. Access other things.
And adding resources is a very special job.. Every resources must be
added for more then one locale. For every possible view of the component
not the default one that is just there when you do
new MyComponent()
but also the resources that are there when i do:
new MyComponent().setRainBowView()
Ad i see we could do it 2 ways.
one an static method on what ever kind of object. that is invoked by us
The static method has to be something like "initResources()"
or an interface method with that same method.
johan
Gili wrote:
I'm not sure I understand. If you have an empty default
constructor like I suggested in #1, constructing a component/page to
find out its resources is dirty cheap. There definately won't be any
sort of DB access going on there...
Did I misunderstand what you meant?
Gili
Johan Compagner wrote:
i don't like making instances of components/pages. Just to get there
resources..
Because pages/components maybe are build for a specific state. they
require other things
The do a lot more (access db) We don't want that.
We just want a simple class that does nothing except registering
resources for one or more componets (that are packaged as one)
johan
Gili wrote:
This is definately sounding much clearer.
JavaBean-style alternative:
1) Component must have a default constructor that does nothing.
2) Component.getNestedComponents() returns a list of nested
components used by this component.
3) Component.getApplicationResources() returns a list of all
resources that must be registered using an application scope.
4) Component.init() contains all the add() calls
Sorta like what Johan just posted in his last email...
Gili
Jonathan Locke wrote:
i think not even property files. just have one file in
META-INF/wicket-components.txt.
each jar (or classloader folder) would have a list here of the
components in the jar. this
is nice and simple. not even a properties file. just a text file.
Johan Compagner wrote:
We are not going to scan for Pages or Components
just use ClassLoader.getResources() ==== Property files.
johan
Gili wrote:
So if I understand this right... you're trying to introduce a
method by which the Application can scan Pages on the classpath
and find out what Application-scoped resources they have, without
constructing them? I think the cost outweighs the benefit here.
But anyway, say you wanted this anyway, why not do what I
suggested a long time ago and separate Page construction from
Page initialization of its nested components?
That is, a Page has a default constructor which basically
does nothing (like JavaBeans). Then you have Page.addComponents()
where one invokes add() and then you can have
Page.getApplicationResources() where one returns all resources
which should be application-scoped. So then the Application scans
the classpath, finds all Pages, constructs them (cheap operation
now), invokes getApplicationResources() and voila! You're done.
And no need for ugly XML configuration files.
Gili
Jonathan Locke wrote:
Johan Compagner wrote:
WicketApplication gets something like: registerComponent()
that must be called in the init of the Application object for
every component it uses (that request this in the doc or
something)
So that that component can register/make its PackageResources
available.
But i don't like this very much
i think some variant of this is probably more the right
approach. i really want resources to stay
scoped by the application. this is better OO and will avoid
conflicts and other issues. seriously.
i think we are on the right track. we should not undo something
that's well-structured and working
to fix this problem. yes, we do have a problem with resource
registration, but i think i have a
fairly decent idea how to fix this...
DESIGN GOALS:
1. enable auto-registration of components and related global
resources
2. put the burden on component designers not users
3. make it easy for component designers to get their
resources registered with the application
4. solution should not interfere with the current simple way
of developing and using components and resources
SOLUTION:
1. user puts component jars and classfiles on classpath and
is blissfully ignorant of what's going on
2. Application constructor enumerates through jars and
classes via ClassLoader.getResources()
looking for xml metadata, each package containing a
Components.xml file
a. each xml file is processed to register resources for
any components in the jar or classpath folder
b. the minimum format for this xml file would be something
like:
<wicket-components>
<wicket-component
class="wicket.whatever.MyComponent" load="true/false">
<resources>
<package-resource path="images/foo.gif"
locale="en_CA" style="sporty"/>
...
</resources>
</wicket-component>
</wicket-components>
resources not registered using the <resource>
declarations for PackageResources would have to
be registered by setting load="true" and using a static
initializer block to do the work.
we can talk more about the format and where the info
should go, but the basic idea seems solid...
2>
Don't bind PackageResources or StaticResources in the
SharedResources.
They are already holding references to the StaticImages inside
them self (there static map)
So shared resources should somehow look there. But we need to
store also the scope/locale and style then.
The you can use them statically and the serializable problems
are gone and the PackageResources are there
BEFORE the page so the page doesn't also have to be
instantiated again. (only the class has to be loaded)
johan
Jonathan Locke wrote:
there is no problem that i'm aware of. you cannot do either
of these things:
- hold a PackageResourceReference (or any other wicket object,
really) in a static field and expect it to work in a web
container that's running multiple applications
- expect a PackageResourceReference to result in a resource
that is retrievable before the page that uses it has been
rendered
if you want an image that is available from the time your
application starts, you MUST store that resource in
ApplicationSettings.getSharedResources() using one of the
add(...) methods.
this has NOTHING to do with ResourceReferences. it has to do
with resources. in the ImagesApplication example, this line:
getSharedResources().add("cancelButton", new
DefaultButtonImageResource("Cancel"));
makes a dynamic button image resource available at this url:
http://localhost:8080/images/resources/application/cancelButton
the application shared resources object is a repository of
Resources which can come from anywhere that are available
through requests to the application outside of any page context.
if you want to have a PackageResource (which is just an image
loaded from a given java package), you would write this:
getSharedResource().add("duke",
PackageResource.get(MyClass.class, "images/duke.gif"));
after executing this line in your application's
initialization, the duke image will be available here:
http://localhost:8080/<app>/resources/application/duke
you don't USE a resource reference to make something global
for all time. a resource reference is the thing that you use
to reference a resource from a component. the confusing thing
is probably that resource references will bind a resource to
the application when they're accessed. but that's being done
to make the resource cacheable and expose it at a constant
url, not to make it a globally static resource for all time.
to do that, you add the resource to the application's
SharedResources. make sense now?
Johan Compagner wrote:
i will look into/do paging this week
I am still not there yet what we should do with
StaticResourceReferences .... (rename is fine by me, but that
still doesn't fix the problems we have with them)
johan
Jonathan Locke wrote:
three new bugs opened that i think really must get fixed for
1.1.
two things to vote on:
1. #1256079 - i'd like to volunteer to do the refactor of
the feedback stuff based on the bug i just submitted based
on the wicket-user discussion on the subject. it's possible
some minor stuff might break, but i think it can be mostly a
compatible change. where it can't be compatible, i'd vote
that we make a breaking change because the new plan for how
to do this is a lot better than the old plan.
2. #1255537 - rename StaticResource->PackageResouce and
StaticResourceReference->PackageResourceReference
i'm +1 on both of these of course and can take care of them
both sometime in the next week or so.
finally, i opened #1256084 - i'd really like someone else to
write this page navigation code package if possible. it's a
fun little project of its own and ought to be /really/ clean
and simple and have nothing to do with listview or any other
component.
jon
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
