You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2009/12/09 02:04:18 UTC
[jira] Created: (TOMAHAWK-1472) Add Support for new Resource API in
tomahawk 2.0 module
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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850772#action_12850772 ]
Leonardo Uribe commented on TOMAHAWK-1472:
------------------------------------------
Committed initial patch of this feature, only for tomahawk core20. It is still pending work on sandbox core20.
Finally use the custom event solution was added. For solve the problem of xxxLocation, the most simple and compatible way is in case this properties are set, use AddResource api.
The only component that we can't move to resource api is t:dojoInitializer. The reason is dojo assumes all resources are served through a directory, but in the case of jsf 2.0, this is not true. It is possible to tweak dojo, but it is better solution to keep using AddResource api. Maybe we should update the old dojo version shipped with tomahawk (0.4.x) to a new version (only in jsf 2.0 branch), but this requires a lot of work, because the idea is update all components on sandbox too.
> 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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Jakob Korherr (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836853#action_12836853 ]
Jakob Korherr commented on TOMAHAWK-1472:
-----------------------------------------
I think making tomahawk for JSF 1.2 with JSP upwards compatible like Werner proposed and using the new resource API for tomahawk 2.0 and facelets 2 is the best way to go. Since most of the new features of JSF 2.0 are facelets only, the developers will have to start using facelets anyway. Also porting a webapp from JSP to facelets on JSF 2.0 is not really a big problem.
Just a thought: We also could use ClientBehaviors which we add automatically to the tomahawk components to render the needed javascript.
> 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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835438#action_12835438 ]
Leonardo Uribe commented on TOMAHAWK-1472:
------------------------------------------
Trying to do this issue I found the following use case (all this snippets happens on renderers)
if( tabbedPane.isClientSide() ){
addResource.addJavaScriptAtPosition(facesContext, AddResource.HEADER_BEGIN, HtmlTabbedPaneRenderer.class, "dynamicTabs.js");
This one is similar:
if (schedule.isTooltip())
{
addResource.addJavaScriptAtPosition(context, AddResource.HEADER_BEGIN,
HtmlSchedule.class, "javascript/alphaAPI.js");
Or this one:
if (DEFAULT_THEME.equals(theme) || OUTLOOK_THEME.equals(theme)
|| EVOLUTION_THEME.equals(theme))
{
addResource.addStyleSheet(context, AddResource.HEADER_BEGIN,
HtmlSchedule.class, CSS_RESOURCE);
}
The new JSF 2.0 Resource Api does not support conditional rendering for resources out of the box. To solve this one, we need the resource has a reference or a way to find the owner resource and check this condition when it is rendered. That means we need a custom resource renderer that check the condition.
Note the condition originally is evaluated each time on render response time, but the new JSF 2.0 Resource Api requires all resources were added before that. We don't have an event that gives the chance to register it before render response.
Other option is copy the value or ValueExpression required in the condition on the resource component, but this does not look good.
We have to try another alternative (a custom component event?), but it is not still clear how to do that.
> 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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861980#action_12861980 ]
Leonardo Uribe commented on TOMAHAWK-1472:
------------------------------------------
Committed fix add LibraryLocationAware and implemented on required components. I think we can close this one for core, only it is pending on sandbox.
> 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
> Assignee: Leonardo Uribe
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836026#action_12836026 ]
Leonardo Uribe commented on TOMAHAWK-1472:
------------------------------------------
After try a lot of alternatives, a custom component event named PreRenderViewAddResourceEvent, called by a ViewHandlerWrapper instance at start of renderView and it works without problem. The renderer looks like this:
@ListenerFor(systemEventClass=PreRenderViewAddResourceEvent.class)
public class HtmlTabbedPaneRenderer
extends HtmlRenderer implements ComponentSystemEventListener
{
public void processEvent(ComponentSystemEvent event)
{
HtmlPanelTabbedPane tabbedPane = (HtmlPanelTabbedPane)event.getComponent();
if( tabbedPane.isClientSide() )
{
FacesContext facesContext = FacesContext.getCurrentInstance();
UIComponent outputScript = facesContext.getApplication().
createComponent(facesContext, "javax.faces.Output", "javax.faces.resource.Script");
outputScript.getAttributes().put("name", "dynamicTabs.js");
outputScript.getAttributes().put("library", "org.apache.myfaces.custom.tabbedpane");
outputScript.setTransient(true);
outputScript.setId(facesContext.getViewRoot().createUniqueId());
facesContext.getViewRoot().addComponentResource(facesContext, outputScript);
.............
It is the easiest solution I can find. Now the next problem is component that has javascriptLocation, imageLocation and styleLocation. This includes:
t:inputCalendar
t:jscookMenu
t:tree2
One option is create new attributes javascriptLibrary, imageLibrary and styleLibrary and remove the previous ones (because if AddResource api will not be used by tomahawk components and we will use the new JSF 2.0 api, there is no point to have this one on the component class). If a user wants to upgrade, it just put all resources on folder on a jar (META-INF/resource/myImagesForThatComponent) or on "resources/myImagesForThatComponent", configure the new attributes and that's all.
Anyway I'll look a way to preserve the old attributes to prevent break existing applications.
> 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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Werner Punz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806096#action_12806096 ]
Werner Punz commented on TOMAHAWK-1472:
---------------------------------------
Id say for people who still want to use JSP just make the tomahawk 1.2 branch upwards compatible (which it should be anyway) and then make a clean cut and from then onwards facelets only.
Did´t we want to do that anyway, because the community wanted the dojo stuff in but the one Ganesh was doing with dojoFaces which relied entirely on faclets?
> 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.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API
in tomahawk 2.0 module
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ 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.