Re: Renderkit using Freemarker templates
The performance question is a good one, but I thought I'd throw something else into the discussion... I've thought about creating something like this a number of times, as a way to make components more flexible for the user. When a component has more complex rendering, I often find I'd like to be able to tweak the generated HTML in ways that simply aren't possible without replacing the renderer. If the renderer was driven by a template *and* there was a supported mechanism for specifying a custom template (on a per-component-use basis or even just on a per-application basis), this would be much easier. On the other hand, the potential for people breaking the component by changing the render template in unexpected ways is a little unsettling... L. Adam Winer wrote: When I've thought of this, I've always imagined that really complex renderers would end up requiring Java code, and that really simple renderers, well, aren't that hard to write in the first place, and would be much slower when written that way. At that point, I gave up and worked on things I was sure would work. :) Templating a la Facelets has seemed like a pretty good middle ground for assembling on-the-fly components. That said, I'd be absolutely thrilled to proven wrong! So I guess two questions: - Have you had a chance to benchmark the Freemarker-coded outputText against the one in MyFaces? - Any chance of tackling a complex component so we could see what it looks like? -- Adam On 6/28/07, Jurgen Lust [EMAIL PROTECTED] wrote: Hi, I think most people will agree that writing Renderers for JSF components using the standard tools, i.e. ResponseWriter.startElement and ResponseWriter.writeAttribute etc., is not very straightforward or productive, especially when creating complex components. If you take a look at org.apache.myfaces.custom.schedule.ScheduleDetailedDayRenderer, you'll know what I mean :) One of the great things about Dojo is that you can create templates for your components. Inspired by this, I tried to do something similar for JSF renderers, using Freemarker. I put it in the sandbox, and wrote a replacement HtmlOutputTextRenderer based on it. I know the outputText is a bad example for this, but for complex stuff, this could be really useful. What do you think? Jurgen
Re: Dojo + myfaces upfront refactoring warning
Werner Punz wrote: The next 1-2 days depending on my schedule there will be minor corrections on the Dojo codebase. The requires and component includes will be moved from the head to the body due to the fact that some dojo components require to have it in the body section. If you have used the codebase there will be a minor change in the DojoUtils class, in the addRequire methods. I will alter all existing components accordingly once my integration tests over here are done. What's the issue that's requiring this change? I haven't had any problems with putting all scripts in the document head, and it certainly *shouldn't* be required to place them in the body. L.
Re: Dojo + myfaces upfront refactoring warning
Werner Punz wrote: Laurie Harper schrieb: Werner Punz wrote: The next 1-2 days depending on my schedule there will be minor corrections on the Dojo codebase. The requires and component includes will be moved from the head to the body due to the fact that some dojo components require to have it in the body section. If you have used the codebase there will be a minor change in the DojoUtils class, in the addRequire methods. I will alter all existing components accordingly once my integration tests over here are done. What's the issue that's requiring this change? I haven't had any problems with putting all scripts in the document head, and it certainly *shouldn't* be required to place them in the body. The issue is that I had a combination of components (one of them probably triggering the problem being the dialog) which caused an error on the dojo debug level. The error was something like dojo.component.manager could not be initialized. I tried the markup in various combinations and moving all the requires and the internal include (not the dojo include) down to the body resolved the problem entirely. Weird. If you could narrow it down to a simple test case demonstrating the problem I'm sure it could be fixed. My first guess would be something other than a dojo.require() happening that needed to be deferred until onLoad, though. I also checked later the dojo examples and the ones I checked, all did the initialization in the body for one reason or the other. Afterwards I also contacted Mario who does the current refactoring of the addresource, and he said he would prefer to have this stuff in the body due to future performance refactoring reasons. So I am going to move the require and component includes down to the body while the dojo include still stays in the head for now. Hmm, I thought there were XHTML compliance issues with having script tags in the body? That's why I queried this in the first place :) Although it appears to work, valid or not. L.
Re: ADF Faces javascript rendering
Werner Punz wrote: Laurie, cannot help you there, but a minor sidequestion, did you use my dojo hooks I provided in the sandbox? If yes please give me feedback if you need something changed or added, now is a perfect time for doing it, the whole dojo base will be moved into Tomahawk after 1.1.2, and then it will be much harder to break existing interfaces if needed. The reason why I am asking is that I need comments and feedback from people who do serious component development so that I get more insight on what is needed (for now I only have the stuff in I need) I had a look through (some of) your Dojo-related code, but haven't used it directly. As you know, I have code of my own in this area ;-) L.
Re: ADF Faces javascript rendering
Mike, thanks for the link. Yes, I'm familiar with the AddResources stuff in Tomahawk, but was looking for the equivalent functionality in ADF Faces so I can inter-operate with either. L. Mike Kienenberger wrote: Have you looked at this? http://wiki.apache.org/myfaces/External_Resources On 2/22/06, Laurie Harper [EMAIL PROTECTED] wrote: The Tomahawk components 'inject' Javascript file references into the head section of the response by using a filter to buffer and post-process the response. I'm assuming ADF Faces has some mechanism for injecting Javascript too, but I can't seem to track it down... I've found the code that handles serving static resources, just not the code responsible for injecting references to Javascript files. The reason I'm looking for it is so I can make a component library I'm working on use it. Can anyone give me a pointer to the right area in the ADF Faces code, or even better a quick explanation of how to use it to do what I want? Thanks, L.
[jira] Created: (TOMAHAWK-155) Move ExtensionsFilter to commons so it can be reused outside Tomahawk
Move ExtensionsFilter to commons so it can be reused outside Tomahawk - Key: TOMAHAWK-155 URL: http://issues.apache.org/jira/browse/TOMAHAWK-155 Project: MyFaces Tomahawk Type: Task Reporter: Laurie Harper Priority: Minor The ExtensionsFilter would be useful across projects. It could be reused by Tobago and/or ADF Faces, and would be useful in other, non-MyFaces component libraries. It would be useful if it were moved to commons to support such reuse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ADF Faces javascript rendering
Mike Kienenberger wrote: On 2/22/06, Laurie Harper [EMAIL PROTECTED] wrote: Maybe it would make sense to move Tomahawk's AddResources / Filter based stuff into commons so it can be re-used across Tomahawk, ADFF, Tobago and other component libraries? I don't see any reason why we can't move that stuff into commons (and actually, I figured it was already in commons), now that we have a commons jar. It's intended as an end-user API. Please open a JIRA issue so we don't forget. You've probably noticed that we're still discussing how commons is going to work :) Maybe it hasn't been done up to this point because the extensions filter isn't included in commons yet. Yeah, that's what I meant; some stuff is in commons already, some stuff is in Tomahawk. Actually, I think most stuff except the filter itself, and maybe the default resource loader impl, are in commons. I added TOMAHAWK-155 to request the filter itself be moved over too. L.
Re: [jira] Commented: (TOMAHAWK-155) Move ExtensionsFilter to commons so it can be reused outside Tomahawk
OK, I wont ask you to rehash the discussion ;-), I'll have to dig out the thread. Thanks for the pointer. On 22-Feb-06, at 7:53 PM, sean schofield (JIRA) wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-155? page=comments#action_12367453 ] sean schofield commented on TOMAHAWK-155: - One issue here is that commons is not really something that we are ready to promote as an independent API. If you read the recent dev threads on this you will see how we are considering moving away from commons as a publicly released project. Eventually there might be a project dedicated to reusable stuff outside of MyFaces but that is not our short term focus. Move ExtensionsFilter to commons so it can be reused outside Tomahawk - Key: TOMAHAWK-155 URL: http://issues.apache.org/jira/browse/TOMAHAWK-155 Project: MyFaces Tomahawk Type: Task Reporter: Laurie Harper Priority: Minor The ExtensionsFilter would be useful across projects. It could be reused by Tobago and/or ADF Faces, and would be useful in other, non-MyFaces component libraries. It would be useful if it were moved to commons to support such reuse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Laurie Harper Open Source advocate, Java geek: http://www.holoweb.net/laurie Founder, Zotech Software: http://www.zotechsoftware.com/
ADF Faces javascript rendering
The Tomahawk components 'inject' Javascript file references into the head section of the response by using a filter to buffer and post-process the response. I'm assuming ADF Faces has some mechanism for injecting Javascript too, but I can't seem to track it down... I've found the code that handles serving static resources, just not the code responsible for injecting references to Javascript files. The reason I'm looking for it is so I can make a component library I'm working on use it. Can anyone give me a pointer to the right area in the ADF Faces code, or even better a quick explanation of how to use it to do what I want? Thanks, L.
Re: Dojo stuff from sandbox to tomahawk
Late to the party, but I can show you how to do this better... ;-)
Firstly, there's no need to use invalid markup with Dojo, provided
you're using XHTML. You can use namespaces. Secondly, I have a Dojo
Editor / JSF integration almost working that would let you simply do this:
dj:inputEdit toolbar=cut;copy;paste;.../
The rendered result is something like this:
textarea id=_jsp1 dojo:widgetId=_jsp1
dojo:type=Editor dojo:items=cut;copy;paste;...
../textarea
If you care about validation, you need to declare the 'dojo' namespace
somewhere, as in (for example)
html xmlns=... xmlns:dojo=http://dojotoolkit.org;
(that's not quite enough, since that namespace URI doesn't point to
anything useful, but you get the idea).
HTH,
L.
Werner Punz wrote:
Actually I would love to have such a passthrough
but probably many people here would object it
due to the fact that the dojo tags break html validation.
(I talked with Alex Russel the dojo core maintainer about this and he said,
that in his opinion being lenient towards such things
is good, because it opens options, but he does not
want to close the doors for people who do not want this, hence
the various possibilities to trigger the components)
Having such a passthrough in the input fields, div and the textara
would enable most dojo components out of the box, without scripting
(although div would break the jsf form submit)
Werner
Mike Kienenberger schrieb:
Aha!
Thanks Werner,
The key was to stick the javascript after the input (and remove the
style). I'd tried a large permutation of these things, but it didn't
occur to me that the javascript needed to be after the input area.
Here's what I ended up doing (in facelets).
Put this in the head tags:
sandbox:dojoInitializer require=dojo.widget.Editor/
Put this in the form:
h:inputTextarea id=contentHtmlEditArea
required=#{true}
value=#{createSimpleAnnouncementPage.text}/
script type=text/javascript
// ![CDATA[
var editorArgs = {
items: [textGroup, blockGroup, justifyGroup, colorGroup,
listGroup, indentGroup, linkGroup]
};
var editor = dojo.widget.fromScript(Editor, editorArgs,
dojo.byId(form:contentHtmlEditArea));
// ]]
/script
I decided to stick with the standard jsf inputAreaText component and
use the fully-qualified path to the component (form-id : component-id)
rather than using forceid.
I agree that s:richEdit id=editor/ would be better. It seems to
me that we could make such a tag emit the same code as I just created
manually, at least in the short term.
I was considering altering t:inputTextArea to support a passthrough
items attribute as a temporary workaround, but it would have been
quite a hack.
I'll go ahead and update the wiki.
On 2/17/06, Werner Punz [EMAIL PROTECTED] wrote:
Hi Mike I can only give pseudo code here,
first of all, in an actual JSF page I would like to see
code like this
s:richEdit id=editor/
but we cannot have that for now:
if you want to see the rich editor in action in a jsf page and if you
want to pass the parameter as well, use a normal textArea
(not the div because the div is not triggered on submit)
t:inputTextarea id=myId forceId=true /
and then set a javascript in a verbatim area with following entries
(we forget the internal dojo id for now, since you wont need it here)
f:verbatim
script type=text/javascript
var editorArgs = {
items: [textGroup, blockGroup,
justifyGroup, colorGroup,
listGroup, indentGroup, linkGroup]
};
var editor = dojo.widget.fromScript(Editor, editorArgs,
dojo.byId(myId));
/script
/f:verbatim
that should work more or less
what happens here
first you define a text area in a form, so that we trigger the normal
jsf submits etc...
secondly dojo now alters the text area into a full blown rich text
editor
via the fromScript function (the first argument specifies the widget
the text area has to be altered to, the second one the arguments passed
down to the area, the third argument is the id of the original control)
now if you submit the altered control recongnizes that passes
the content into the original control (which still is lingering there
hidden) and the cycle goes through as expected.
the reason why this code does not give you a second editor while
your code does is following line:
h:inputTextarea id=contentHtmlEditArea
styleClass=dojo-Editor
!
what happens here is that you explicetly pass the
styleClass=dojo-Editor which in itself also creates the dojo editor
you also trigger the editor creation script, hence you create
two editors from one single control (both internally with different ids)
you have two options, either remove the javascript for the component
creation, or remove the styleClass with the dojo-Editor style.
But having both results in two editors.
So basically for most if not
[jira] Created: (MYFACES-1089) commandLink incorrectly accepts 'onclick' attribute
commandLink incorrectly accepts 'onclick' attribute --- Key: MYFACES-1089 URL: http://issues.apache.org/jira/browse/MYFACES-1089 Project: MyFaces Type: Bug Components: General Versions: 1.1.1 Reporter: Laurie Harper Priority: Minor myfaces_html.tld incorrectly lists an 'onclick' attribute for the commandLink comonent tag. 'onclick' is not valid for this component per the JSF reference documentation: http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/tlddocs/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
