Igor Vaynberg wrote:
I see your point about the raw access, but I still /really/ don't like the
new approach. Its an extra file to maintain and on top of it it doesn't even
true, but only a component implementer ever even has to know about this
file...
live inside the package side by side with the files its referencing. It will
become a headache. I think we need to put some thought into coming up with a
better solution, the current one feels too "disconnected" to me.
we're open to ideas, but they do have to support the existing component
usage patterns.
Have an image service that only allows certain extensions, hava a javascript
service, or let the users implement their own with their custom filters.
That way you don't need to initialize anything up front and the whole thing
is simpler. Cant you handle dynamic resources the same way - generate an
image inside the service which is a singleton relative to the application
and stream it out - no clustering problems? You would end up registering the
services with the application object and you can cover all your images with
one service as opposed to having to list them all one by one.
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?
that's the same amount of pain and
has the same bootstrapping problem that we have now. the problem that
we're solving with this discovery
process is that some random component out there on the classpath is
going to have to make its resource
available to requesters /before any instance of that component has even
been created/... for example, if
the app server restarts in a cluster... it can get a request out of the
blue for the dynamic resource that the
component rendered out to a browser on a different machine... how else
can you hook up the component's
resource? you have to go find the available components with resources
like this when the app server restarts.
i don't like the idea of "service" objects particularly. the word is
nearly meaningless. and the existing resource
structure is really pretty good if you take the time to understand it.
if there are ways we can improve what
we've got, that's great. but the architecture that's there is there to
support a particular set of usage patterns.
But this is just my 2 cents.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jonathan Locke
Sent: Wednesday, August 10, 2005 7:23 PM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging navigation
Igor Vaynberg wrote:
Nice thing about wicket is that even if I am a component developer I
can just share the java/html files w/out having to worry about other
external files.
What do you gain by bootstrapping a component? This sounds like an
issue of
for one thing, you could register a dynamic resource so that
it's available during a clustering restart or for a request
that comes before the page that references the resource
renders. wicket resources are not just file based. see
DynamicImageResource and subclasses... but other kinds of
resources could be dynamically generated as well. without
the change that i just checked in, i don't think our dynamic
button images could really work in a cluster. now, i think
you can make them work because they can be registered by the
component when it is initialized through IComponentInitializer.
retrieving files from a package structure as opposed to file
structure
under the context. Be it required javascript/images/whatever. Just
package them with your component and build a simple url to them.
the trouble with just using a raw file structure is that it
is implict and might leave resources in the folder open to
downloading that were not intended for it. i'm open to
changing my mind on this like anything, but i like the idea
of keeping tight control over what resources are exposed by
the application. i think a better way to do this might be to
allow a component to register multiple PackageResources with
a wildcard.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Wednesday, August 10, 2005 4:24 PM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
i just want the component developer to write it. the user
doesn't do
anything...
Igor Vaynberg wrote:
Hopefully there wont be any configuration file I have to
maintain, be
it a text file or an xml file :) -Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Wednesday, August 10, 2005 4:15 PM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
the problem is really about bootstrapping components. i
think we've
got it under control.
our approach will be dirt simple.
Igor Vaynberg wrote:
I don't want to butt in in the middle of something I
don't totally
understand, but here is my two cents anyways:
The problem is that you cannot access an image inside a
package without
a resourcereference created?
Getting back to my previous suggestion of tapestry-like services
Tapestry has an asset service that given a package-name of
a resouce
simply streams it to the response so you can access any
image or any
other file by constructing a simple url:
http://blahblah.com/myapp/app?service=asset&asset=wicket.exam
ple.image1
.jpg
This eliminates any need for static resource references and
since url
is always the same the asset gets cached by the browser.
Am I totally off the field here?
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gili
Sent: Wednesday, August 10, 2005 3:57 PM
To: [email protected]
Subject: Re: [Wicket-develop] feedback refactor and paging
navigation
it is not a workaround.
Nobody and i really think nobody is going to add all
the static
resources the datepicker is needing in there application
including you
This needs to be fixed.
Well, all I know is... because people couldn't hit
screenshots off my
website without constructing a Page. This now works. So
I'm happy.
It's certainly a step in the right direction. And no, I
don't use the
DatePicker :)
Jon suggested using an XML configuration file. I
suggested adding
a method to components (I mistakenly said Page but I
meant for all
components) that allows them to return a list of all
resources they
wish to export. etc..
Yes but you still need to know WHAT components what to
contribute.
so this must be configured/registered somehow.
i don't want xml either. just a simple property file.
Ok, so I won't suggest the exact details of how to
accomplish this,
but let me ask: why don't we declare an interface which all
components
must implement which will make this possible (a la JavaBean) as
opposed to using property files? I'd prefer having this
sort of thing
as part of the Class, something I run through a
compiler and gets
compile-time validation.
Gili
-------------------------------------------------------
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
