myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API in tomahawk 2.0 module
Date Wed, 27 Jan 2010 22:52:34 GMT

    [ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805681#action_12805681
] 

Leonardo Uribe commented on TOMAHAWK-1472:
------------------------------------------

In order to provide the community a way to "contribute" or "hear" how will be tomahawk for
jsf 2.0 module, it is better to do a full
discussion of this issue here.

First of all we need a comparison between Resource API and Tomahawk AddResource API, to identify
possible problems of use one of another.

TOMAHAWK RESOURCE API

    The AddResource api is used for add and server resources. It is capable of serve static
and dynamic resources. Below there is a list of
    the classes involved with a brief description of the purpose:
    
    AddResourceFactory: This class provides the ability to instantiate AddResource objects.
By default it check if the environment is correctly set.
    
    AddResource: This interface defines methods necessary to render links to resources used
by custom components. Mostly used to avoid having 
    to include [script src="..."][/script] in the head of the pages before using a component.
    
    ResourceLoader: A class which can interpret the URI generated by a corresponding ResourceHandler
implementation, locate that resource 
    and write it to the servlet response stream.
    
    ResourceProvider: A class which can provide the resource itself. It represents a resource
like Resource class in jsf 2.0, but it is used only
    on the algorithm that serve resources
    
    ResourceHandler: Represents a single resource that a component in a page needs a  browser
to fetch. This class helps generate the URI 
    that is emitted into the page, and specifies the class that should be invoked to handle
the request for that URI when the browser makes it.
    
    Below there is a list of components using AddResource api:
    
    t:inputCalendar
    t:inputDate
    t:captcha
    t:documentHead
    t:dojoInitializer
    t:inputHtml
    t:inputTextHelp
    t:jsValueChangeListener
    t:panelNavigation2
    t:jscookMenu
    t:selectManyPicklist
    t:popup
    t:schedule
    t:swapImage
    t:panelTab
    t:togglePanel
    t:tree
    t:tree2
    t:stylesheet
    
    It is possible to use several strategies to put resources in a web page:
    
    NonBufferingAddResource: Put the link or script directly on the web page, in other words,
it inserts them into the body of the page instead. 
    Used in portlets.
    StreamingAddResource: Works like NonBufferingAddResource, but has a hack with t:documentHead
to solve the problem with css styles on head section.
    DefaultAddResource:  When used together with the ExtensionsFilter, this class can allow
components in the body of a page to emit script and stylesheet 
    references into the page head section. The relevant methods on this object simply queue
the changes, and when the page is complete 
    the ExtensionsFilter calls back into this class to allow it to insert the commands into
the buffered response.
    
    There are different ways to serve resources:
    
    MyFacesResourceLoader: Look the javascript file scanning the package "org.apache.myfaces.custom".
    StreamingResourceLoader: Allows the hack with t:documentHead to solve the problem with
css styles.
    CAPTCHARenderer: Render the image used by t:captcha.

NEW JSF 2.0 RESOURCE API

    In JSF 2.0 a new api was introduced to solve the problem of Resource Handling. This tags
were introduced in this version:
    
    h:head
    h:body
    h:outputScript
    h:outputStylesheet
    
    This tags DO NOT exists in JSP, because all new features are for facelets, now bundled
with JSF. By default, it only handle static resources.

DISCUSSION

    If we load all resources used by components with the new api, pages created with JSF 1.2
or earlier will not work on JSP as is. We could implement 
    a variant of h:head, h:body, h:outputScript and h:outputStylesheet that works for jsp.
t:head and t:body are easy but t:outputScript 
    and t:outputStylesheet cannot be relocated on the component tree, instead we need to create
a "copy" to register it in UIViewRoot, using a 
    custom JSP Tag class.

    The current implementation of javax.faces.webapp.UIComponentELTag calls Application.createComponent(componentType)
and 
    Application.createComponent(ValueExpression, FacesContext, componentType). The problem
with this one is that renderers are not scanned 
    looking for ResourceDependency or ListenerFor annotations, but it is not a big deal, because
we can put those annotations on component class
    instead.

    If someone wants to run tomahawk using its resource api, there is no technical reason
why not run tomahawk12 with myfaces core 2.0 in JSP. 
    
    Use tomahawk resource api and the new jsf 2.0 resource api seems to be confusing. Finally
we end in all renderers with the following:
 
    if (usingAddResourceApiOnComponents)
    {
        callAddResourceApiToLoadMyScriptOrStylesheet
    }
    
    but note the new api requires register resources before render view phase, so one choice
could be registered on the component. If we use 
    addResourceApi and h:head or t:head we will end with duplicate resource references. At
the end, it seems more easier add t:head 
    or h:head and do not use addResource api.

    In theory we can add resources on PreRenderViewEvent, instead of register resources using
a ResourceDependency annotation. In this case, we
    need a check for duplicate resources.
    
CONCLUSION

    It seems deprecate tomahawk resource api and create a wrapper to handle dynamic resources
the best way to go. We should not worry too much about JSP
    support, because it is possible to run applications with JSF 2.0 and tomahawk for JSF
1.2 in JSP mode. It's more the problems and the unnecessary 
    complexity than the real benefit. Also, port existing applications from JSP to Facelets
is not very hard. If we do it in this way, it will be easier 
    for users to understand tomahawk code, because we KEEP THINGS SIMPLE!. The philosophy
behind tomahawk is a jsf library simple to use, 
    easy to understand, and compatible with other libraries. Also, in the begining, tomahawk
was called "myfaces extensions", so all components that needs
    some specific hack to run with myfaces core implementation are here (Ex: t:aliasBean)
and this library has been a place to try and test myfaces core stuff.
    Backward compatibility is good but we have to move on. 

Suggestions, critics and tomatoes are welcome.

> Add Support for new Resource API in tomahawk 2.0 module
> -------------------------------------------------------
>
>                 Key: TOMAHAWK-1472
>                 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1472
>             Project: MyFaces Tomahawk
>          Issue Type: Task
>            Reporter: Leonardo Uribe
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message