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