You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Emond Papegaaij <em...@topicus.nl> on 2011/12/02 09:33:44 UTC
Experimental work on ResourceReference management
Hi all,
For the past few weeks, and especially the last few days, Hielke Hoeve and I
have been working on improvements to resource management in Wicket. Most of
the improvements are based on work in WiQuery, but the actual implementation
is from scratch. The targets for the improvements can be found in WICKET-4273.
In short, it boils down to following points:
- Dependency support for resources
- Sorting of resources in the header
- Native resource bundle support in Wicket
- Aggregating many small scripts into 1 large script tag, esp. for events
The target for these changes will be Wicket 6 and the work in progress can be
found on github:
https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
At the moment, all features, except the resource bundles are implemented and
working. Documentation is still missing on most places. I've also not yet come
to writing tests and an example on how to use it.
Please provide your feedback on the code, here on the mailing list or at JIRA.
Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
because there was a large overlap in functionality, and it proved difficult to
keep the old code working as is. It would be great if you could shed some
light on what the exact problem was, you were trying to solve with that code,
so I can make sure that it can also be solved with this new approach.
Best regards,
Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Igor Vaynberg <ig...@gmail.com>.
sweet, dont forget to attach your patch to the jira issue when you are done...
-igor
On Wed, Dec 14, 2011 at 6:47 AM, Emond Papegaaij
<em...@topicus.nl> wrote:
> Hi all,
>
> I've finished most of the work on the branch, including some of the
> suggestions that were made in this thread. IHeaderResponse now has only 1
> render method left, which takes a HeaderItem. This simplified everything
> related to IHeaderResponse quite a bit, and also fixed WICKET-4247. I've also
> implemented the circular dependency detection, fixed the original example to
> use the new API and added javadoc in most places.
>
> Things that still need to be done:
> - Finish javadoc
> - Add some more tests
> - Fix WICKET-4000 and WIKCET-4235 (which I'd rather do after this branch has
> been merged into wicket)
>
> The code can still be found on github at:
> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>
> Best regards,
> Emond
>
> On Friday 02 December 2011 09:33:44 Emond Papegaaij wrote:
>> Hi all,
>>
>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>> have been working on improvements to resource management in Wicket. Most of
>> the improvements are based on work in WiQuery, but the actual
>> implementation is from scratch. The targets for the improvements can be
>> found in WICKET-4273. In short, it boils down to following points:
>> - Dependency support for resources
>> - Sorting of resources in the header
>> - Native resource bundle support in Wicket
>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>
>> The target for these changes will be Wicket 6 and the work in progress can
>> be found on github:
>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>
>> At the moment, all features, except the resource bundles are implemented and
>> working. Documentation is still missing on most places. I've also not yet
>> come to writing tests and an example on how to use it.
>>
>> Please provide your feedback on the code, here on the mailing list or at
>> JIRA.
>>
>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>> because there was a large overlap in functionality, and it proved difficult
>> to keep the old code working as is. It would be great if you could shed
>> some light on what the exact problem was, you were trying to solve with
>> that code, so I can make sure that it can also be solved with this new
>> approach.
>>
>> Best regards,
>> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Peter Ertl <pe...@gmx.org>.
And sorry for typing your name wrong …
Am 14.12.2011 um 15:59 schrieb Peter Ertl:
> That's awesome, Edmond!
>
> Thanks! :-)
>
> Am 14.12.2011 um 15:47 schrieb Emond Papegaaij:
>
>> Hi all,
>>
>> I've finished most of the work on the branch, including some of the
>> suggestions that were made in this thread. IHeaderResponse now has only 1
>> render method left, which takes a HeaderItem. This simplified everything
>> related to IHeaderResponse quite a bit, and also fixed WICKET-4247. I've also
>> implemented the circular dependency detection, fixed the original example to
>> use the new API and added javadoc in most places.
>>
>> Things that still need to be done:
>> - Finish javadoc
>> - Add some more tests
>> - Fix WICKET-4000 and WIKCET-4235 (which I'd rather do after this branch has
>> been merged into wicket)
>>
>> The code can still be found on github at:
>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>
>> Best regards,
>> Emond
>>
>> On Friday 02 December 2011 09:33:44 Emond Papegaaij wrote:
>>> Hi all,
>>>
>>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>>> have been working on improvements to resource management in Wicket. Most of
>>> the improvements are based on work in WiQuery, but the actual
>>> implementation is from scratch. The targets for the improvements can be
>>> found in WICKET-4273. In short, it boils down to following points:
>>> - Dependency support for resources
>>> - Sorting of resources in the header
>>> - Native resource bundle support in Wicket
>>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>>
>>> The target for these changes will be Wicket 6 and the work in progress can
>>> be found on github:
>>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>>
>>> At the moment, all features, except the resource bundles are implemented and
>>> working. Documentation is still missing on most places. I've also not yet
>>> come to writing tests and an example on how to use it.
>>>
>>> Please provide your feedback on the code, here on the mailing list or at
>>> JIRA.
>>>
>>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>>> because there was a large overlap in functionality, and it proved difficult
>>> to keep the old code working as is. It would be great if you could shed
>>> some light on what the exact problem was, you were trying to solve with
>>> that code, so I can make sure that it can also be solved with this new
>>> approach.
>>>
>>> Best regards,
>>> Emond Papegaaij
>
Re: Experimental work on ResourceReference management
Posted by Peter Ertl <pe...@gmx.org>.
That's awesome, Edmond!
Thanks! :-)
Am 14.12.2011 um 15:47 schrieb Emond Papegaaij:
> Hi all,
>
> I've finished most of the work on the branch, including some of the
> suggestions that were made in this thread. IHeaderResponse now has only 1
> render method left, which takes a HeaderItem. This simplified everything
> related to IHeaderResponse quite a bit, and also fixed WICKET-4247. I've also
> implemented the circular dependency detection, fixed the original example to
> use the new API and added javadoc in most places.
>
> Things that still need to be done:
> - Finish javadoc
> - Add some more tests
> - Fix WICKET-4000 and WIKCET-4235 (which I'd rather do after this branch has
> been merged into wicket)
>
> The code can still be found on github at:
> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>
> Best regards,
> Emond
>
> On Friday 02 December 2011 09:33:44 Emond Papegaaij wrote:
>> Hi all,
>>
>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>> have been working on improvements to resource management in Wicket. Most of
>> the improvements are based on work in WiQuery, but the actual
>> implementation is from scratch. The targets for the improvements can be
>> found in WICKET-4273. In short, it boils down to following points:
>> - Dependency support for resources
>> - Sorting of resources in the header
>> - Native resource bundle support in Wicket
>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>
>> The target for these changes will be Wicket 6 and the work in progress can
>> be found on github:
>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>
>> At the moment, all features, except the resource bundles are implemented and
>> working. Documentation is still missing on most places. I've also not yet
>> come to writing tests and an example on how to use it.
>>
>> Please provide your feedback on the code, here on the mailing list or at
>> JIRA.
>>
>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>> because there was a large overlap in functionality, and it proved difficult
>> to keep the old code working as is. It would be great if you could shed
>> some light on what the exact problem was, you were trying to solve with
>> that code, so I can make sure that it can also be solved with this new
>> approach.
>>
>> Best regards,
>> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi all,
I've finished most of the work on the branch, including some of the
suggestions that were made in this thread. IHeaderResponse now has only 1
render method left, which takes a HeaderItem. This simplified everything
related to IHeaderResponse quite a bit, and also fixed WICKET-4247. I've also
implemented the circular dependency detection, fixed the original example to
use the new API and added javadoc in most places.
Things that still need to be done:
- Finish javadoc
- Add some more tests
- Fix WICKET-4000 and WIKCET-4235 (which I'd rather do after this branch has
been merged into wicket)
The code can still be found on github at:
https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
Best regards,
Emond
On Friday 02 December 2011 09:33:44 Emond Papegaaij wrote:
> Hi all,
>
> For the past few weeks, and especially the last few days, Hielke Hoeve and I
> have been working on improvements to resource management in Wicket. Most of
> the improvements are based on work in WiQuery, but the actual
> implementation is from scratch. The targets for the improvements can be
> found in WICKET-4273. In short, it boils down to following points:
> - Dependency support for resources
> - Sorting of resources in the header
> - Native resource bundle support in Wicket
> - Aggregating many small scripts into 1 large script tag, esp. for events
>
> The target for these changes will be Wicket 6 and the work in progress can
> be found on github:
> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>
> At the moment, all features, except the resource bundles are implemented and
> working. Documentation is still missing on most places. I've also not yet
> come to writing tests and an example on how to use it.
>
> Please provide your feedback on the code, here on the mailing list or at
> JIRA.
>
> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
> because there was a large overlap in functionality, and it proved difficult
> to keep the old code working as is. It would be great if you could shed
> some light on what the exact problem was, you were trying to solve with
> that code, so I can make sure that it can also be solved with this new
> approach.
>
> Best regards,
> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Emond Papegaaij <em...@topicus.nl>.
As the work continues on the branch, Hielke provided the first testcases, I
fixed many and I implemented support for resource bundles:
https://github.com/papegaaij/wicket/commit/c7cd30046728568981e96251d7f6d627d06958a9
(until I decide to rebase again :) ), for all changes in the branch:
https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
Resource bundles are completely transparent on the side of the components,
where resources are added. If one of the resources from a bundle is added, the
bundle is added in stead. All other resources are marked as already added.
This allows you to register bundles for external libraries, without the
library knowing about the bundles. You can create the bundles manually, or use
a concatenating resource.
Documentation is still mostly missing and an example is also needed, just as
some more tests.
Reading through some issues on JIRA, I guess WICKET-4000 and WICKET-4235 could
also be fixed with this. Some changes will be needed to header rendering to
let HeaderResponse render wicket:head header contributions, but that's no
problem for Wicket 6.
Best regards,
Emond Papegaaij
On Friday 02 December 2011 09:33:44 Emond Papegaaij wrote:
> Hi all,
>
> For the past few weeks, and especially the last few days, Hielke Hoeve and I
> have been working on improvements to resource management in Wicket. Most of
> the improvements are based on work in WiQuery, but the actual
> implementation is from scratch. The targets for the improvements can be
> found in WICKET-4273. In short, it boils down to following points:
> - Dependency support for resources
> - Sorting of resources in the header
> - Native resource bundle support in Wicket
> - Aggregating many small scripts into 1 large script tag, esp. for events
>
> The target for these changes will be Wicket 6 and the work in progress can
> be found on github:
> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>
> At the moment, all features, except the resource bundles are implemented and
> working. Documentation is still missing on most places. I've also not yet
> come to writing tests and an example on how to use it.
>
> Please provide your feedback on the code, here on the mailing list or at
> JIRA.
>
> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
> because there was a large overlap in functionality, and it proved difficult
> to keep the old code working as is. It would be great if you could shed
> some light on what the exact problem was, you were trying to solve with
> that code, so I can make sure that it can also be solved with this new
> approach.
>
> Best regards,
> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Emond Papegaaij <em...@topicus.nl>.
I'm sorry for the late reply, we are in the middle of a migration from svn to
git and that's taking most of my time at the moment.
Igor:
I already renamed the classes as you suggested, added a warning when the
minified version cannot be found and changed the file-extension detection.
I tried to rewrite both resource references as a wrapper around
PackageResourceReference, but that proved quite difficult. You somehow have to
intercept the call to getName() in the resource reference itself, because its
value gets passed to the resource directly. The only solutions I see are:
- wrapping the resource, which still requires quite some changes to the
resource
- adding a second getResource to PackageResourceReference method that takes
all values as parameters
- adding a setName to PackageResourceReferences
I do not like any of these solutions, so I will leave it for now and see if I
can come up with something better later on. Whatever solution is chosen, it
needs to prevent duplicate resources that can result from adding a minified
and a full version, this is not solved yet.
The option to disable the use of minified resources commes from WiQuery. We
don't use it, but perhaps other do. I don't care if it is removed.
Igor and Peter:
Don't you think preventing infinity loops is the resposibillity of the
developer? After all, the developer declares the dependencies. The check can
become quite costly, because you have to search in the list of
RecordedHeaderItem.recordedLocations or keep a list of all added dependencies
while adding them. I haven't tried catching the StackOverflowError that you
would get, perhaps that would work? Another option would be to limit the depth
of the dependencies to 100 for example and throw an exception at 100 recursive
iterations.
I do like the idea of rewriting IHeaderResponse to use HeaderItem, or
IHeaderItem or whatever works best. However, that would be a rather big
refactoring which I'd rather do after introducing the real features. Also, I'm
not sure if this would read very well:
response.render(JavaScriptHeaderItem.forReference(JQueryResourceReference.get()));
It's a bit more verbose than:
response.renderJavaScriptReference(JQueryResourceReference.get());
Peter:
The wasRendered and markRendered are part of the public API of
IHeaderResponse. They are also used by Component and Behavior to track
rendering of resources. If these methods are changed, that part of the
rendering needs to be changed as well and we do need some replacement, because
I (mis)use then to know when rendering for a certain component starts and
ends.
Best regards,
Emond
On Monday 05 December 2011 14:25:59 Peter Ertl wrote:
> maybe we could get rid of some 'generic' declarations and replace
>
> IHeaderResponse#wasRendered(Object) with
> IHeaderResponse#wasRendered(IHeaderItem)
> IHeaderResponse#markRendered(Object) with
> IHeaderResponse#markRendered(IHeaderItem)
>
> IHeaderResponse#renderString(CharSequence) with
> IHeaderResponse#renderString(StringHeaderItem) [or just use a generic
> render(IHeaderItem) like Igor suggested)
> Am 05.12.2011 um 14:18 schrieb Peter Ertl:
> > my 2%
> >
> > - introduce interface IHeaderItem (next to abstract class HeaderItem)
> > and use that where possible so migration of existing resources will be
> > easier - rename render(IHeaderResponse) to renderHead(IHeaderResponse)
> > to avoid confusion since 'render(response)' looks to much like it
> > renders all, not just the head. - what happens if you have cyclic
> > dependencies?
> >
> > Am 03.12.2011 um 17:17 schrieb Igor Vaynberg:
> >> also since we now have HeaderItem and its used in the core part of the
> >> framework (ResourceReference) why not refactor IHeaderResponse to just
> >> have one render(HeaderItem) instead of the ton of methods in there
> >> now...
> >>
> >> -igor
> >>
> >> On Sat, Dec 3, 2011 at 7:29 AM, Igor Vaynberg <ig...@gmail.com>
wrote:
> >>> looks really good. here are some notes:
> >>>
> >>> * MinifiedDetecting*->MinifiedAware*
> >>> * MinifiedDetecting*#getName() needs to have a code comment saying
> >>> that the code inside has to be threadsafe so when people tweak it
> >>> they
> >>> are aware of it
> >>> * can the MinifiedDetecting* be made into a wrapper instead of
> >>> different subclasses
> >>> * MinifiedDetecting* doesnt check for the actual file extension, it
> >>> assumes that its either js or css
> >>> * MinifiedDetecting* should warn if minified resource is missing
> >>>
> >>> * ResourceAggrator -> ResourceAggrator
> >>> * ResourceAggrator#renderResources() make sure this is
> >>> infinite-recursion-proof if two dependencies reference each other
> >>> * i dont think getResourceSettings().getUseMinifiedResources() is
> >>> necessary, just use application's developmentmode flag
> >>>
> >>> -igor
> >>>
> >>> On Fri, Dec 2, 2011 at 12:33 AM, Emond Papegaaij
> >>>
> >>> <em...@topicus.nl> wrote:
> >>>> Hi all,
> >>>>
> >>>> For the past few weeks, and especially the last few days, Hielke
> >>>> Hoeve and I have been working on improvements to resource
> >>>> management in Wicket. Most of the improvements are based on work
> >>>> in WiQuery, but the actual implementation is from scratch. The
> >>>> targets for the improvements can be found in WICKET-4273. In
> >>>> short, it boils down to following points:
> >>>> - Dependency support for resources
> >>>> - Sorting of resources in the header
> >>>> - Native resource bundle support in Wicket
> >>>> - Aggregating many small scripts into 1 large script tag, esp. for
> >>>> events
> >>>>
> >>>> The target for these changes will be Wicket 6 and the work in
> >>>> progress can be found on github:
> >>>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwique
> >>>> ry
> >>>>
> >>>> At the moment, all features, except the resource bundles are
> >>>> implemented and working. Documentation is still missing on most
> >>>> places. I've also not yet come to writing tests and an example on
> >>>> how to use it.
> >>>>
> >>>> Please provide your feedback on the code, here on the mailing list
> >>>> or at JIRA.
> >>>>
> >>>> Note to Jeremy: I deleted some of the code you contributed to
> >>>> Wicket 1.5 because there was a large overlap in functionality,
> >>>> and it proved difficult to keep the old code working as is. It
> >>>> would be great if you could shed some light on what the exact
> >>>> problem was, you were trying to solve with that code, so I can
> >>>> make sure that it can also be solved with this new approach.
> >>>>
> >>>> Best regards,
> >>>> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Peter Ertl <pe...@gmx.org>.
maybe we could get rid of some 'generic' declarations and replace
IHeaderResponse#wasRendered(Object) with IHeaderResponse#wasRendered(IHeaderItem)
IHeaderResponse#markRendered(Object) with IHeaderResponse#markRendered(IHeaderItem)
IHeaderResponse#renderString(CharSequence) with IHeaderResponse#renderString(StringHeaderItem) [or just use a generic render(IHeaderItem) like Igor suggested)
Am 05.12.2011 um 14:18 schrieb Peter Ertl:
> my 2%
>
> - introduce interface IHeaderItem (next to abstract class HeaderItem) and use that where possible so migration of existing resources will be easier
> - rename render(IHeaderResponse) to renderHead(IHeaderResponse) to avoid confusion since 'render(response)' looks to much like it renders all, not just the head.
> - what happens if you have cyclic dependencies?
>
>
> Am 03.12.2011 um 17:17 schrieb Igor Vaynberg:
>
>> also since we now have HeaderItem and its used in the core part of the
>> framework (ResourceReference) why not refactor IHeaderResponse to just
>> have one render(HeaderItem) instead of the ton of methods in there
>> now...
>>
>> -igor
>>
>> On Sat, Dec 3, 2011 at 7:29 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> looks really good. here are some notes:
>>>
>>> * MinifiedDetecting*->MinifiedAware*
>>> * MinifiedDetecting*#getName() needs to have a code comment saying
>>> that the code inside has to be threadsafe so when people tweak it they
>>> are aware of it
>>> * can the MinifiedDetecting* be made into a wrapper instead of
>>> different subclasses
>>> * MinifiedDetecting* doesnt check for the actual file extension, it
>>> assumes that its either js or css
>>> * MinifiedDetecting* should warn if minified resource is missing
>>>
>>> * ResourceAggrator -> ResourceAggrator
>>> * ResourceAggrator#renderResources() make sure this is
>>> infinite-recursion-proof if two dependencies reference each other
>>> * i dont think getResourceSettings().getUseMinifiedResources() is
>>> necessary, just use application's developmentmode flag
>>>
>>> -igor
>>>
>>> On Fri, Dec 2, 2011 at 12:33 AM, Emond Papegaaij
>>> <em...@topicus.nl> wrote:
>>>> Hi all,
>>>>
>>>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>>>> have been working on improvements to resource management in Wicket. Most of
>>>> the improvements are based on work in WiQuery, but the actual implementation
>>>> is from scratch. The targets for the improvements can be found in WICKET-4273.
>>>> In short, it boils down to following points:
>>>> - Dependency support for resources
>>>> - Sorting of resources in the header
>>>> - Native resource bundle support in Wicket
>>>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>>>
>>>> The target for these changes will be Wicket 6 and the work in progress can be
>>>> found on github:
>>>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>>>
>>>> At the moment, all features, except the resource bundles are implemented and
>>>> working. Documentation is still missing on most places. I've also not yet come
>>>> to writing tests and an example on how to use it.
>>>>
>>>> Please provide your feedback on the code, here on the mailing list or at JIRA.
>>>>
>>>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>>>> because there was a large overlap in functionality, and it proved difficult to
>>>> keep the old code working as is. It would be great if you could shed some
>>>> light on what the exact problem was, you were trying to solve with that code,
>>>> so I can make sure that it can also be solved with this new approach.
>>>>
>>>> Best regards,
>>>> Emond Papegaaij
>
Re: Experimental work on ResourceReference management
Posted by Peter Ertl <pe...@gmx.org>.
my 2%
- introduce interface IHeaderItem (next to abstract class HeaderItem) and use that where possible so migration of existing resources will be easier
- rename render(IHeaderResponse) to renderHead(IHeaderResponse) to avoid confusion since 'render(response)' looks to much like it renders all, not just the head.
- what happens if you have cyclic dependencies?
Am 03.12.2011 um 17:17 schrieb Igor Vaynberg:
> also since we now have HeaderItem and its used in the core part of the
> framework (ResourceReference) why not refactor IHeaderResponse to just
> have one render(HeaderItem) instead of the ton of methods in there
> now...
>
> -igor
>
> On Sat, Dec 3, 2011 at 7:29 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> looks really good. here are some notes:
>>
>> * MinifiedDetecting*->MinifiedAware*
>> * MinifiedDetecting*#getName() needs to have a code comment saying
>> that the code inside has to be threadsafe so when people tweak it they
>> are aware of it
>> * can the MinifiedDetecting* be made into a wrapper instead of
>> different subclasses
>> * MinifiedDetecting* doesnt check for the actual file extension, it
>> assumes that its either js or css
>> * MinifiedDetecting* should warn if minified resource is missing
>>
>> * ResourceAggrator -> ResourceAggrator
>> * ResourceAggrator#renderResources() make sure this is
>> infinite-recursion-proof if two dependencies reference each other
>> * i dont think getResourceSettings().getUseMinifiedResources() is
>> necessary, just use application's developmentmode flag
>>
>> -igor
>>
>> On Fri, Dec 2, 2011 at 12:33 AM, Emond Papegaaij
>> <em...@topicus.nl> wrote:
>>> Hi all,
>>>
>>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>>> have been working on improvements to resource management in Wicket. Most of
>>> the improvements are based on work in WiQuery, but the actual implementation
>>> is from scratch. The targets for the improvements can be found in WICKET-4273.
>>> In short, it boils down to following points:
>>> - Dependency support for resources
>>> - Sorting of resources in the header
>>> - Native resource bundle support in Wicket
>>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>>
>>> The target for these changes will be Wicket 6 and the work in progress can be
>>> found on github:
>>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>>
>>> At the moment, all features, except the resource bundles are implemented and
>>> working. Documentation is still missing on most places. I've also not yet come
>>> to writing tests and an example on how to use it.
>>>
>>> Please provide your feedback on the code, here on the mailing list or at JIRA.
>>>
>>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>>> because there was a large overlap in functionality, and it proved difficult to
>>> keep the old code working as is. It would be great if you could shed some
>>> light on what the exact problem was, you were trying to solve with that code,
>>> so I can make sure that it can also be solved with this new approach.
>>>
>>> Best regards,
>>> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Igor Vaynberg <ig...@gmail.com>.
also since we now have HeaderItem and its used in the core part of the
framework (ResourceReference) why not refactor IHeaderResponse to just
have one render(HeaderItem) instead of the ton of methods in there
now...
-igor
On Sat, Dec 3, 2011 at 7:29 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> looks really good. here are some notes:
>
> * MinifiedDetecting*->MinifiedAware*
> * MinifiedDetecting*#getName() needs to have a code comment saying
> that the code inside has to be threadsafe so when people tweak it they
> are aware of it
> * can the MinifiedDetecting* be made into a wrapper instead of
> different subclasses
> * MinifiedDetecting* doesnt check for the actual file extension, it
> assumes that its either js or css
> * MinifiedDetecting* should warn if minified resource is missing
>
> * ResourceAggrator -> ResourceAggrator
> * ResourceAggrator#renderResources() make sure this is
> infinite-recursion-proof if two dependencies reference each other
> * i dont think getResourceSettings().getUseMinifiedResources() is
> necessary, just use application's developmentmode flag
>
> -igor
>
> On Fri, Dec 2, 2011 at 12:33 AM, Emond Papegaaij
> <em...@topicus.nl> wrote:
>> Hi all,
>>
>> For the past few weeks, and especially the last few days, Hielke Hoeve and I
>> have been working on improvements to resource management in Wicket. Most of
>> the improvements are based on work in WiQuery, but the actual implementation
>> is from scratch. The targets for the improvements can be found in WICKET-4273.
>> In short, it boils down to following points:
>> - Dependency support for resources
>> - Sorting of resources in the header
>> - Native resource bundle support in Wicket
>> - Aggregating many small scripts into 1 large script tag, esp. for events
>>
>> The target for these changes will be Wicket 6 and the work in progress can be
>> found on github:
>> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>>
>> At the moment, all features, except the resource bundles are implemented and
>> working. Documentation is still missing on most places. I've also not yet come
>> to writing tests and an example on how to use it.
>>
>> Please provide your feedback on the code, here on the mailing list or at JIRA.
>>
>> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
>> because there was a large overlap in functionality, and it proved difficult to
>> keep the old code working as is. It would be great if you could shed some
>> light on what the exact problem was, you were trying to solve with that code,
>> so I can make sure that it can also be solved with this new approach.
>>
>> Best regards,
>> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Igor Vaynberg <ig...@gmail.com>.
looks really good. here are some notes:
* MinifiedDetecting*->MinifiedAware*
* MinifiedDetecting*#getName() needs to have a code comment saying
that the code inside has to be threadsafe so when people tweak it they
are aware of it
* can the MinifiedDetecting* be made into a wrapper instead of
different subclasses
* MinifiedDetecting* doesnt check for the actual file extension, it
assumes that its either js or css
* MinifiedDetecting* should warn if minified resource is missing
* ResourceAggrator -> ResourceAggrator
* ResourceAggrator#renderResources() make sure this is
infinite-recursion-proof if two dependencies reference each other
* i dont think getResourceSettings().getUseMinifiedResources() is
necessary, just use application's developmentmode flag
-igor
On Fri, Dec 2, 2011 at 12:33 AM, Emond Papegaaij
<em...@topicus.nl> wrote:
> Hi all,
>
> For the past few weeks, and especially the last few days, Hielke Hoeve and I
> have been working on improvements to resource management in Wicket. Most of
> the improvements are based on work in WiQuery, but the actual implementation
> is from scratch. The targets for the improvements can be found in WICKET-4273.
> In short, it boils down to following points:
> - Dependency support for resources
> - Sorting of resources in the header
> - Native resource bundle support in Wicket
> - Aggregating many small scripts into 1 large script tag, esp. for events
>
> The target for these changes will be Wicket 6 and the work in progress can be
> found on github:
> https://github.com/papegaaij/wicket/compare/trunk...wicket%2Bwiquery
>
> At the moment, all features, except the resource bundles are implemented and
> working. Documentation is still missing on most places. I've also not yet come
> to writing tests and an example on how to use it.
>
> Please provide your feedback on the code, here on the mailing list or at JIRA.
>
> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
> because there was a large overlap in functionality, and it proved difficult to
> keep the old code working as is. It would be great if you could shed some
> light on what the exact problem was, you were trying to solve with that code,
> so I can make sure that it can also be solved with this new approach.
>
> Best regards,
> Emond Papegaaij
Re: Experimental work on ResourceReference management
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Fri, Dec 2, 2011 at 3:33 AM, Emond Papegaaij
<em...@topicus.nl>wrote:
> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
> because there was a large overlap in functionality, and it proved
> difficult to
> keep the old code working as is. It would be great if you could shed some
> light on what the exact problem was, you were trying to solve with that
> code,
> so I can make sure that it can also be solved with this new approach.
>
Emond,
It sounds like you have the use-cases pretty well covered. Basically,
the goal of that work was to be able to define a hierarchy of resources
that depended on each other. To be able to get that into 1.4 there were
some design compromises. But, it enabled us to be able to include a single
resource and make sure that any other resources that were required by it
were included before it. (For example, including a custom jQuery module
could force jQuery to be loaded before the module).
Thanks for your efforts! It sounds like you are making good progress for
a nice improvement to resources for Wicket 6!
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*