yes that would be nice.
But i don't think there is a way to scan (file.list()) inside a jar on the classpath i think
Have to look in the api for that

But still what does a static path (a string) mean for cameron?
What does that string represent when it is inside a jar?
Is it a url?

johan


Eelco Hillenius wrote:
I think what Cameron means - and I agree with that - is that it would
be very convenient to be able to register everything in a package with
one command. Of course, the /implementation/ of that command is to
scan the package and register every resource found one at a time.

Eelco


On 9/6/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
but at what time do you want to do it?
Because that has to be done anyway..

I still don't see why a String (staticroot) would help you with that
instead of just directly use the Dojo.class

johan


Cameron Braid wrote:
Its just a pain to have to register EVERY SINGLE static resource.

Cameron


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:wicket-develop-
[EMAIL PROTECTED] On Behalf Of Johan Compagner
Sent: Tuesday, 6 September 2005 7:19 PM
To: [email protected]
Subject: Re: [Wicket-develop] Ideas for better Dojo support

why register a folder?
why not just use the class itself (as scope)
because as far as i can see that is what you want.
You want the package == scope == the Dojo.class

johan


Cameron Braid wrote:

I think that being able to register a folder, and optionally a filter,

to

export a folder of static resources would still be a good idea.

Cameron



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:wicket-

develop-

[EMAIL PROTECTED] On Behalf Of Eelco Hillenius
Sent: Tuesday, 6 September 2005 6:08 PM
To: [email protected]
Subject: Re: [Wicket-develop] Ideas for better Dojo support

With other javascript/ css dependencies (like with the DatePicker) the
relative resolving works. As long as all dependencies are
pre-registered. This could be more elagant, agreed on that. It should
be easy to scan a package and automatically register the resources we
find in it based on e.g. extensions.

Why do you want to use an initializer? This looks like more work. If
you use AjaxHandlers, like DojoAjaxHandler, the registering and header
contribution is done automatically for you. And there is a seperation
between contributions that should be done once (the static .js file
includes) and contributions that should be done for every ajax
handler. Doesn't this suit your needs? And if not, what do you find
inconvenient in our ajax handler pattern?

Eelco


-------------------------------------------------------
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

Reply via email to