-Igor
On 8/9/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Johan Compagner wrote:
> We now have this:
>
> public interface IHeaderContributor extends Serializable
> {
> void renderHead(final Response response);
> }
>
> why not make it this:
>
> public interface IHeaderContributor extends Serializable
> {
> void renderHead(final IHeaderResponse response);
> }
>
> public interface IHeaderResponse
> {
> public void renderJavascriptReference (PackageResourceReference
> reference);
>
> public void renderCSSReference(PackageResourceReference reference);
>
> public void renderString(String string);
>
> public void markRendered(Object object);
>
> public boolean wasRendered(Object object);
> }
>
> Then the implementation of that could be a Response (a StringResponse
> subclass implementing that interface)
> or a Class that has a instanceof a Response in it.
>
> We could add one extra method (getResponse()) so that if you really want
> to have the response you can get it.
>
> Then we dont have those ugly static methods on something. We don't need
> a ThreadLocal to keep the set
> that can be done in the instance of IHeaderResponse just as fine.
>
> So where we now have:
>
> protected void onRenderHeadInitContribution(final Response response)
> {
> writeJsReference(response, _javascript_);
> }
>
> we could just do
>
> protected void onRenderHeadInitContribution(final IHeaderResponse response)
> {
> response.renderJavascriptReference(_javascript_);
> }
>
So far I agree, except that
protected void onRenderHeadInitContribution(final IHeaderResponse response)
should read renderHead(final IHeaderResponse response), shouldn't it?
(method from IHeaderContributor)
So... erm... who's going to... erm... implement this?
-Matej
> Much nicer if you ask me and for developers that are coding these header
> contributors
> it is much more self explaining. You dont need to know about a vague
> class with some static methods
> that you should call instead of directly the response.write()
>
> But maybe i am missing something right now that i am not seeing at this
> late hour ...
>
> Johan
>
>
> On 8/9/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> On ##wicket we came to a conclusion that we need to unify and simplify
> the way duplicated header contributions are filtered. We want to make it
> as simple as possible, but yet powerful enough to be able to handle
> non-trivial usecases.
>
> The current draft looks like this:
>
> public class HeaderContribution
> {
> static public void
> renderJavascriptReference(PackageResourceReference
> reference, Response response);
>
> static public void renderCSSReference(PackageResourceReference
> reference, Response response);
>
> static public void renderString(String string, Response
> response);
>
> static public void markRendered(Object object);
>
> static public boolean wasRendered(Object object);
>
> static public void detach();
> }
>
> The usage should be like this:
>
> class MyBehavior extends AbstractBehavior
>
> private static PackageResourceReference myJavascript = ...;
>
> private static PackageResourceReference myCSS = ...;
>
> protected void renderHead(Response resp) {
> HeaderContribution.renderJavascriptReference(myJavascript,
> response);
> HeaderContribution.rednerCSSReference (myCss, response);
> }
>
> ...
> }
>
> Where HeaderContribution would take care of filtering duplicate
> contributions (using a Threadlocal containing a set of already
> contributed objects).
>
> Thoughs?
>
> -Matej
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> <mailto: Wicket-develop@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
