[Tobago] Rendered troubles
Hello!
I use the next code (I dropped here some componets like f:facet to
shorter message)
tc:panel
tc:gridLayout rows=fixed;20px;1*/
tc:box/
tc:cell/
tc:sheet rendered=#{!empty maSearchForm.mailAccounts}/
tc:cell rendered=#{empty maSearchForm.mailAccounts}/
When maSearchForm.mailAccounts is empty, the page renders correct.
Otherwise I get exception. Is this normal or am I doing something wrong?
|java.lang.ArrayIndexOutOfBoundsException: 3
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.layoutHeight(GridLayoutRenderer.java:571)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.layoutEnd(GridLayoutRenderer.java:480)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:233)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:262)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:45)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:47)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:45)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:357)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:262)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.PageRenderer.encodeEnd(PageRenderer.java:126)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:252)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:573)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:167)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:477)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:591)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:513)
at java.lang.Thread.run(Thread.java:595)
|
With respect,
Boris
Re: Standardcompliance of rendered markup
Hi Jeff,
the problem with the t:panelNavigation2/-tag can be reproduced as follows:
I defined a tiles template containing a t:panelNavigation2/
f:view
h:form
t:div id=menu forceId=true
t:div id=lftBar forceId=true
f:loadBundle
basename=resources.example_messages
var=example_messages /
t:div id=subnavigation_outer forceId=true
t:div id=subnavigation forceId=true
t:panelNavigation2 id=nav1 layout=list
itemClass=mypage
activeItemClass=selected
openItemClass=selected
t:navigationMenuItems
value=#{navigationMenu.panelNavigationItems} /
/t:panelNavigation2
/t:div
/t:div
/t:div
f:subview id=contentView
div id=content
tiles:insert name=body flush=false /
/div
/f:subview
/t:div
/h:form
/f:view
Now there can be distinguish two cases:
1.) When I include a page1.jsp for the content-placeholder with a
h:commandLink/ inside, the menu works as it should.
Example for page1.jsp:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
h:outputText value=Page2/
h:outputText escape=false value=br//
h:commandLink value=Link action=test/
2.) When I include page2.jsp for the content-placeholder without link,
but just textoutput, the menu dosn't work. It dosn't trigger the
faces-lifecycle on the server.
Example for page2.jsp:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
h:outputText value=Page2/
If this is realy an error, could't you please report it as a bug?
Thank you,
Rudi
On 4/5/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Hi Rudi, comments inline.
[2] http://people.apache.org/builds/myfaces/nightly/
[3] https://issues.apache.org/jira/browse/MYFACES-1414
Rudi Steiner wrote:
Hi Jeff,
testing again the current version bevor taliking about bugs is a great
idea ;)
The problem for beginners like me is, that on the myFaces website is
described, that the fastest way to get a project up and running is to
take one of the example-apps (in my case the tiles-app) and take this
structure to start the own project. The problem is, that the sample
apps dont use the latest version 1.1.5 of myFaces but version 1.1.1.
If the sample apps would use the latest versions, the sample-apps
would be a big help for beginners to construct a new app.
Actually, mon ami, they do. :)
You must be grabbing the wrong examples file. Try going to link [2] and
grabbing the file tomahawk-examples-1.1.5-SNAPSHOT-bin. You are
probably thinking but that's tomahawk, not myfaces? Well they are the
same example apps as what you've downloaded, just newer. You can read a
more detailed explanation from [3]. The confusion is not your fault: we
need to release a new Tomahawk which includes the examples directly on
the download page. We also then need to update that getting started page
so it points to these tomahawk examples, instead of confusing you into
thinking you need the old 1.1.1 examples. I have just now added a
comment to issue [3] to that effect.
One more question: As I'm using tiles, is it good practice to enclose
the h:form/ - tag within the template, surrounding all the
placeholders and subviews. In this way, I wouldn't have to use a
second form/ for all pages?
Sorry, I don't use Tiles but if it's anything like the other mechanisms
I have used, then yes you can do this.
With my new, version 1.1.5-based application I found out, that the
t:panelNavigation2/-tag dosn't render a dummyForm if enclosed in a
h:form/-tag but the navigation just works, if there is one regular
link on the site (for example a h:commandLink/). If there is no
link, the navigation dosn't trigger the lifecycle on the server. Is
this a known problem?
Hmm this sounds familiar, as if someone else mentioned this on another
thread earlier. However, a quick search of JIRA and the mail archives
didn't turn up anything relevant... Any chance you could provide a
small, contained example of this problem? Then we could start a JIRA for
it to get fixed.
Thank you in advance,
Rudi
On 4/4/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
I'm sorry I meant to say Rudi. ;)
Jeff Bischoff wrote:
Ridu, what version of MyFaces and Tomahawk are you using?
Re: [OT] Canvasing for a MyFaces/JSF Speaker
JSFDays 07 ? any links ? On 4/5/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Hi Maybe Ed could do it on his way to Vienna (JSFDays 07) ;) regards Alexander -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 4:08 PM To: users@myfaces.apache.org Subject: [OT] Canvasing for a MyFaces/JSF Speaker Hi I am canvasing for a speaker for later in the year (Summer, Autumn) who can give a talk to the JAVAWUG UK in London about JavaServer Faces and/or My Faces software development. Please contact me offline peter dot pilgrim at gmail dot com, if interested http://jroller.com/page/javawug http://jroller.com/page/peter_pilgrim -- Peter Pilgrim UBS Investment Bank, Client Portal Dev LDN, Triton Court, 14 Finsbury Square, London, EC2A 1PD United Kingdom ( +44 (0)207 56 75692 ) :: Java EE Spring 2.0 Hibernate 3.2 Development :: Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Tobago] Rendered troubles
Hi Boris,
you need to put a layout constraint for EACH component into the lyaout.
in this case you have 4 components, so you need 4 tokens, even when
two of them are mutually exclusive.
try tc:gridLayout rows=fixed;20px;1*;1*/
Regards,
Volker
2007/4/6, Boris Kovalenko [EMAIL PROTECTED]:
Hello!
I use the next code (I dropped here some componets like f:facet to
shorter message)
tc:panel
tc:gridLayout rows=fixed;20px;1*/
tc:box/
tc:cell/
tc:sheet rendered=#{!empty maSearchForm.mailAccounts}/
tc:cell rendered=#{empty maSearchForm.mailAccounts}/
When maSearchForm.mailAccounts is empty, the page renders correct.
Otherwise I get exception. Is this normal or am I doing something wrong?
|java.lang.ArrayIndexOutOfBoundsException: 3
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.layoutHeight(GridLayoutRenderer.java:571)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.layoutEnd(GridLayoutRenderer.java:480)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:233)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:262)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:45)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:47)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:45)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:357)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:262)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.PageRenderer.encodeEnd(PageRenderer.java:126)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:252)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:573)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:167)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:477)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:591)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:513)
at java.lang.Thread.run(Thread.java:595)
|
With respect,
Boris
Re: New to MyFaces
Iordanov, Borislav (GIC) schrieb: I’m not sure what “statistics” you are looking for. I haven’t done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn’t work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
[Tobago] More popup example
Hello! How to use tc:popup? I looked into sheet example but can't understand how to implement with my code. What I wan to do: I have a sheet where rows are displayed. Each row has a column with tc:button. I want when user press the button the popup open with edit form. Thanks in advance. With respect, Boris
[Tobago] More popup example
Hello! How to use tc:popup? I looked into sheet example but can't understand how to implement with my code. What I wan to do: I have a sheet where rows are displayed. Each row has a column with tc:button. I want when user press the button the popup open with edit form. Thanks in advance. With respect, Boris
Re: Seam and Tomahawk Scheduler
This sounds like a classloader-problem: You should maybe check where
you deploy your tomahawk-jars - maybe you have it in two different
locations (and thereby classloaders)?
2007/4/5, Fabio Duo [EMAIL PROTECTED]:
Hello,
I am trying to use the Tomahawk Scheduler Component together with seam. But
I get some very strange behavior. I've tried the Binding Method and only
filling the Model. I always used the example Paged and Classes.
With the Binding Method I get a Error Message:
java.lang.ClassCastException:
org.apache.myfaces.custom.schedule.HtmlSchedule cannot be cast to org.
apache.myfaces.custom.schedule.HtmlSchedule
It doesn't makes a lot of sense in my opinion.
If I give the Model to the Component I don't receive a Error, but I only see
a Day view. Shows no entries and it's also impossible to change the view or
update the model.
Init:
.
.
ScheduleModel model = new SimpleScheduleModel();
model.setMode(ScheduleModel.MONTH);
scheduleHandler.setModel(model);
HtmlSchedule schedule = new HtmlSchedule();
bindingScheduleHandler.setSchedule(schedule);
Contexts.getSessionContext().set(bindingScheduleHandler,
bindingScheduleHandler);
Contexts.getSessionContext().set(scheduleHandler, scheduleHandler);
Contexts.getSessionContext().set(scheduleSettings, scheduleSettings);
Contexts.getSessionContext().set(model, model);
.
.
Binding:
Binding.xhtml:
...
...
ui:define name=body
h1Login/h1
pPlease login using any username and password/p
h:messages styleClass=message/
f:view
h:form
!-- The schedule itself --
t:div style=position: absolute; left: 220px; top: 5px;
right: 5px;
t:schedule value=#{bindingScheduleHandler.model}
id=schedule1
binding=#{bindingScheduleHandler.schedule}
rendered=true
visibleEndHour=#{scheduleSettings.visibleEndHour}
visibleStartHour=#{scheduleSettings.visibleStartHour}
workingEndHour=#{scheduleSettings.workingEndHour}
workingStartHour=#{scheduleSettings.workingStartHour}
readonly=#{scheduleSettings.readonly}
theme=#{scheduleSettings.theme}
tooltip=#{scheduleSettings.tooltip}
headerDateFormat=#{scheduleSettings.headerDateFormat}
compactWeekRowHeight=#{scheduleSettings.compactWeekRowHeight}
compactMonthRowHeight=#{scheduleSettings.compactMonthRowHeight}
detailedRowHeight=#{scheduleSettings.detailedRowHeight}
mouseListener=#{bindingScheduleHandler.scheduleClicked}
action=#{bindingScheduleHandler.scheduleAction}
/
h:outputText
value=#{bindingScheduleHandler.mouseActionText}/h:outputText
/t:div
!-- The column on the left, containing the calendar and
other controls --
t:div style=position: absolute; left: 5px; top: 5px;
width: 210px; overflow: auto
h:panelGrid columns=1
t:inputCalendar id=scheduleNavigator
value=#{bindingScheduleHandler.model.selectedDate} /
h:commandButton
actionListener=#{bindingScheduleHandler.addSampleEntries}
value=add sample entries /
h:commandButton
actionListener=#{bindingScheduleHandler.addSampleHoliday}
value=add sample holiday /
/h:panelGrid
/t:div
/h:form
/f:view
/ui:define
/ui:composition
Model Value:
!DOCTYPE composition PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
ui:composition xmlns=http://www.w3.org/1999/xhtml;
xmlns:s=http://jboss.com/products/seam/taglib;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:t=http://myfaces.apache.org/tomahawk;
head
link href=stylesheet/basic.css rel=stylesheet type=text/css /
/head
f:view
h:form
!-- The schedule itself --
t:div style=position: absolute; left: 220px; top: 5px;
right: 5px;
t:schedule value=#{model} id=schedule
rendered=true visibleEndHour=18
visibleStartHour=8
workingEndHour=17 workingStartHour=9
readonly=false
theme=evolution tooltip=true/
/t:div
!-- The column on the left, containing the calendar and
other controls --
t:div style=position: absolute; left: 5px; top: 5px;
width: 210px; overflow: auto
h:panelGrid columns=1
t:inputCalendar id=scheduleNavigator
Re: [Tobago] Problem with ActionListener for tc:tree/
Hi Madan,
Thanks for your repsonse.
It's working now :-).
regards
Cyrill
On 3/30/07, madan chowdary [EMAIL PROTECTED] wrote:
Hi Cyrill,
place the following code(with respect to urs) in between tc:tree and
/tc:tree
f:facet name=treeNodeCommand
tc:command actionListener=#{inventorySearch.browseCategories}
action=#{inventorySearch.showSearchResults} /
/f:facet
Regards,
Madan
- Original Message
From: Cyrill Zadra [EMAIL PROTECTED]
To: MyFaces Discussion users@myfaces.apache.org
Sent: Friday, 30 March, 2007 5:30:08 PM
Subject: Re: [Tobago] Problem with ActionListener for tc:tree/
Hi all,
I'm just confronted with the same problem at the moment. Has anybody a
solution?
my jsf tobago code:
tc:tree value=#{demo.tree} id=tree idReference=
userObject.id
nameReference=userObject.name showIcons=true
showJunctions=true
showRootJunction=true showRoot=true selectable=none
mutable=false tipReference=userObject.name
f:actionListener type=
ch.filebrowser.actionlistener.TreeEditor /
/tc:tree
thx reagrds
Cyrill
On 2/2/07, madan chowdary [EMAIL PROTECTED] wrote:
Hi all,
I have a issue regarding the Tree's ActionListener.
When i click on one of my nodes in the tree, i need to fire an event.
I used the following code as below to display my tree.
Was able to get the tree and see the underlying nodes in that.
But when i click on the nodes, the ActionListener is not invoked.
tc:box label=#{bundle.categoriesBoxTitle}
f:facet name=layout
tc:gridLayout/
/f:facet
tc:tree value=#{category.categoryTree}
state=#{category.categoryTreeState }
id=categoryTree
idReference=userObject.id
nameReference=userObject.name
showIcons=#{category.showIcons}
showJunctions=#{category.showJunctions}
showRootJunction=#{
category.showRootJunction}
showRoot=#{category.showRoot}
selectable=#{category.treeSelectMode}
mutable=#{category.mutable}
actionListener=#{
inventorySearch.browseCategories}
f:actionListener type=
com.resmed.store.frontend.controller.CategoryListener/
/tc:tree
/tc:box
Regards,
Madan
--
Here's a new way to find what you're looking for - Yahoo! Answers
http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/
--
Here's a new way to find what you're looking for - Yahoo!
Answershttp://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/
[Tobago] Tree server or client-side toggle
Hi all, At the moment I'm working with Tobago's tree element. I'm looking for a similar feature like server and client-side toggling, that can be found in the tomahawk tree2 component. Has Tobago's tc:tree/ component this feature or how could it be implemented? I read that there is a new tc:tree/ Version upcoming? Is such a feature planned in the next version? thanks regards Cyrill
Is it possible to use Facelet partially??? (Desactivate xhtml validation???)
Hi, I have to add some feature to an existing application based on JSF but that dont make use of Facelet. I should like to add my new pages but I should like to use Facelets. I tried it..; it work fine for my part… but not for the rest of application because existing application is not XHTML compliant. Is it possible to desactivate the Facelet xhtml validation for a part of the site? Thanks. Clinckart Stephane
Re: [Tobago] More popup example
Hi Boris, inside the tc:button/ , place the popup related code and u ll be getting the popup when the button is clicked. Hope this code snippet helps you tc:sheet tc:column label=Click Button tc:button label=Click Here id=buttonId tc:attribute name=renderedPartially value=sheetConfigPopup/ f:facet name=popup tc:popup width=400px height=400px id=sheetConfigPopup tc:box label=Popup %-- Your contents goes here --% /tc:box /tc:popup /f:facet /tc:attribute /tc:button /tc:column /tc:sheet Regards, Madan - Original Message From: Boris Kovalenko [EMAIL PROTECTED] To: MyFaces Discussion users@myfaces.apache.org Sent: Friday, 6 April, 2007 2:16:30 PM Subject: [Tobago] More popup example Hello! How to use tc:popup? I looked into sheet example but can't understand how to implement with my code. What I wan to do: I have a sheet where rows are displayed. Each row has a column with tc:button. I want when user press the button the popup open with edit form. Thanks in advance. With respect, Boris __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/
Re: Is it possible to use Facelet partially??? (Desactivate xhtml validation???)
You'll have more luck at [EMAIL PROTECTED]
Re: Is it possible to use Facelet partially??? (Desactivate xhtml validation???)
Sorry [EMAIL PROTECTED] [EMAIL PROTECTED] On 4/6/07, Cagatay Civici [EMAIL PROTECTED] wrote: You'll have more luck at [EMAIL PROTECTED]
RE: [OT] Canvasing for a MyFaces/JSF Speaker
ist in Arbeit... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, April 06, 2007 9:34 AM To: MyFaces Discussion Subject: Re: [OT] Canvasing for a MyFaces/JSF Speaker JSFDays 07 ? any links ? On 4/5/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Hi Maybe Ed could do it on his way to Vienna (JSFDays 07) ;) regards Alexander -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 4:08 PM To: users@myfaces.apache.org Subject: [OT] Canvasing for a MyFaces/JSF Speaker Hi I am canvasing for a speaker for later in the year (Summer, Autumn) who can give a talk to the JAVAWUG UK in London about JavaServer Faces and/or My Faces software development. Please contact me offline peter dot pilgrim at gmail dot com, if interested http://jroller.com/page/javawug http://jroller.com/page/peter_pilgrim -- Peter Pilgrim UBS Investment Bank, Client Portal Dev LDN, Triton Court, 14 Finsbury Square, London, EC2A 1PD United Kingdom ( +44 (0)207 56 75692 ) :: Java EE Spring 2.0 Hibernate 3.2 Development :: Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
How to configure a custom Lifecycle?
Hi *, for better ajax integration tobago has a own lifecycle implementation, since 1.0.11-SNAPSHOT see [1]. Now i'm searching for the best way to configure the use of the implementation. According to the spec the lifecycle is taken from the LifecylceFactory using a lifcycleId, but i can't find a way to specify the lifecycle id to use. Currently tobago has a own LifecycleFactory (this was easy to configure) to return the TobagoLifecycle when the defaultLifecycle is requested, but i would prefer to have a own lifecycle id, and inject the tobagoLifecycle into the default LifcycleFactory on application startup. Regards, Volker [1]:https://issues.apache.org/jira/browse/TOBAGO-312
Re: AW: AW: JSF and Tiles
Peter Dahm schrieb: Not yet, but I have to do it soon. Furthermore on Shale Clay as well ….. Bu I have currently developed a little prototyp and would like to move to the newest my faces version and I’m a little bit confused how comlicated this is …. Actually introducing facelets into a project is either a lot of rework or a no brainer, depending on your structure. The main problem is that facelets requires xhmtl or jspx, if you are not in this domain then be prepared for a major overhaul, if you are then you basically are set with a few lines of code per page... On the other hand I personally think facelets are superior to tiles in many ways, first of all, you gain a lot of performance, secondly they are way more natural to use. Thirdly id is very easy to get a render side componentization (almost as easy as macros in velocity which do the same) I never really felt comfortable with tiles as templating.
Re: [OT] Canvasing for a MyFaces/JSF Speaker
cool, count me in! On 4/6/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, yes, there'll be one, if we ever get the conference website up and running. There should be something out soon! regards, Martin On 4/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: JSFDays 07 ? any links ? On 4/5/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Hi Maybe Ed could do it on his way to Vienna (JSFDays 07) ;) regards Alexander -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 4:08 PM To: users@myfaces.apache.org Subject: [OT] Canvasing for a MyFaces/JSF Speaker Hi I am canvasing for a speaker for later in the year (Summer, Autumn) who can give a talk to the JAVAWUG UK in London about JavaServer Faces and/or My Faces software development. Please contact me offline peter dot pilgrim at gmail dot com, if interested http://jroller.com/page/javawug http://jroller.com/page/peter_pilgrim -- Peter Pilgrim UBS Investment Bank, Client Portal Dev LDN, Triton Court, 14 Finsbury Square, London, EC2A 1PD United Kingdom ( +44 (0)207 56 75692 ) :: Java EE Spring 2.0 Hibernate 3.2 Development :: Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: How to configure a custom Lifecycle?
't that a web.xml context-param ? On 4/6/07, Volker Weber [EMAIL PROTECTED] wrote: Hi *, for better ajax integration tobago has a own lifecycle implementation, since 1.0.11-SNAPSHOT see [1]. Now i'm searching for the best way to configure the use of the implementation. According to the spec the lifecycle is taken from the LifecylceFactory using a lifcycleId, but i can't find a way to specify the lifecycle id to use. Currently tobago has a own LifecycleFactory (this was easy to configure) to return the TobagoLifecycle when the defaultLifecycle is requested, but i would prefer to have a own lifecycle id, and inject the tobagoLifecycle into the default LifcycleFactory on application startup. Regards, Volker [1]:https://issues.apache.org/jira/browse/TOBAGO-312 -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: New to MyFaces
Iordanov, Borislav (GIC) ++ i have worked 6 months on jsf and given it up and wrote my html code direct into the servlet. the reason is: the whole control is under my hand, the rendered code is much simplier, works faster, consumes less space and is more flexible. we have spent one week for binding a table to a model and making it editable and ajax-able wihch took too much time. and when an exception occured, it was hard to detect the reason. one more thing which i disliked about about jsf was a big bug which was solved in newer versions but took much time for us and delayed the project. the reason was a simple synchronization problem where multiple threads accessed an object without synch. On 4/6/07, Werner Punz [EMAIL PROTECTED] wrote: Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
RE: New to MyFaces
seems that mileage really varies We have heard from projects that they never would have made it in time without JSF given their scarce resources. Thinking about the bad maintainability of System.out. webapps I am HAPPY using JSF. Wouldn't want to go back to those old times. And using Facelets even the component-writing is really fun. regards Alexander -Original Message- From: taylan saldiray [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 2:25 PM To: MyFaces Discussion; [EMAIL PROTECTED] Subject: Re: New to MyFaces Iordanov, Borislav (GIC) ++ i have worked 6 months on jsf and given it up and wrote my html code direct into the servlet. the reason is: the whole control is under my hand, the rendered code is much simplier, works faster, consumes less space and is more flexible. we have spent one week for binding a table to a model and making it editable and ajax-able wihch took too much time. and when an exception occured, it was hard to detect the reason. one more thing which i disliked about about jsf was a big bug which was solved in newer versions but took much time for us and delayed the project. the reason was a simple synchronization problem where multiple threads accessed an object without synch. On 4/6/07, Werner Punz [EMAIL PROTECTED] wrote: Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
Re: dynamic list of hyperlinks
That's probably a good point. I've NEVER used t:dataList in a mode
other than simple. It would make sense to improve the example.
I'll open a JIRA issue.
On 4/6/07, Alec Swan [EMAIL PROTECTED] wrote:
I thought that t:dataList can only list text entries because that was all
examples/dataList.jsp was showing.
Thank you for the code snippet.
On 4/5/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
t:dataList can list whatever you like. Why do you think it can only
list text entries?
t:dataList in basic form is simply an iterator -- you can render
whatever you like on each iteration.
Actual code from one of my older projects:
t:dataList
rendered=#{0 != jstl:length(announcement.contentList)}
layout=simple
value=#{
announcement.contentList}
var=content
h:commandLink
action=#{
editAnnouncementsPage.gotoAnnouncementContentListRelationship}
value=#{content.UIDisplayLabel}/
br/
/t:dataList
In a more modern project, I'd use f:setPropertyActionListener (or
t:updateActionListener under jsp) to pass the value to the next page.
On 4/5/07, Alec Swan [EMAIL PROTECTED] wrote:
Hi,
I am using the lates MyFaces, Facelets and Tomahawk releases.
I need to display a list of hyperlinks, which will work similar to a
menu.
When a user clicks on a link the page refreshes with the information
related
to the clicked link.
For example, suppose I have a list of products supplied by the backing
bean.
I would like to list links to each product page in a row. When the user
clicks on the link the page gets refreshed with the product information.
I looked at t:dataList, but it seems that it can only list text entries
and
not links.
1. What is the right way to do this?
2. Is there a way to avoid appending product id to the URL and instead
store
it in the user session when the link is clicked?
3. Are there any related examples I can look at?
Thanks.
Re: New to MyFaces
On 4/6/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: seems that mileage really varies We have heard from projects that they never would have made it in time without JSF given their scarce resources. Thinking about the bad maintainability of System.out. webapps I am HAPPY using JSF. Wouldn't want to go back to those old times. And using Facelets even the component-writing is really fun. regards Alexander I agree with this fully.For me, each project I did in JSF got progressively easier and more pleasurable to deal with. Despite the books and tutorials I read about JSF from the start, the only thing that really made me like it was actually working with it and learning when and how to utilize different parts of the spec. And I mean really LEARNING about it; not hitting a wall and giving up. I cursed and became frustrated, but I kept going. Things seemed impossible at first because I was trying to do them incorrectly. Several subsequent projects taught me about phase listeners, validators, components, render-kits, and when/how to use them together--all things that I knew existed from the start, but not how they really worked in practice. And because of that, with each new project I was able to make better decisions and difficult things became simple. I've done five projects in it, start to finish, and I still probably have things to learn. Harlan
Re: New to MyFaces
I agree with this fully.For me, each project I did in JSF got progressively easier and more pleasurable to deal with. Despite the books and tutorials I read about JSF from the start, the only thing that really made me like it was actually working with it and learning when and how to utilize different parts of the spec. And I mean really LEARNING about it; not hitting a wall and giving up. I cursed and became frustrated, but I kept going. Things seemed impossible at first because I was trying to do them incorrectly. Several subsequent projects taught me about phase listeners, validators, components, render-kits, and when/how to use them together--all things that I knew existed from the start, but not how they really worked in practice. And because of that, with each new project I was able to make better decisions and difficult things became simple. I've done five projects in it, start to finish, and I still probably have things to learn. There are several obstacles that make it difficult to get going with JSF. The API may be very flexible, but is not designed for usage in mind. Writing jsp-based components is a mess. Documentation has still a long way to go: To figure out how to write a converter that can handle reference objects instead of value objects took me quite some time. Having two implementations of one specification doesn't help at all, especially when writing components: Either I use only classes defined in the spec, duplicating lots of standard stuff like, or I make myself dependant on one particular implementation, and can't switch to the other one. I hope that the JSF community can settle to provide only one single implementation for JSF 2.0, and make that as rock-solid as, say, Spring. I you'd ask me, I'd say anyway: Drop JSF managed beans and use only Springs container... Still, haven't finished yet the two projects I'm working on with JSF...
RE: Re: New to MyFaces
I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
RE: New to MyFaces
Well, obviously having some framework to base your application on may be better when you don't know where to start. In that sense, JSF is better than System.out webapps (not sure what exactly you mean by that, though) as any other framework would be. If you only know how to do System.out webapps or JSF webapps, than yes go with JSF -Original Message- From: Jesse Alexander (KSFD 121) [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 9:22 AM To: MyFaces Discussion Subject: RE: New to MyFaces seems that mileage really varies We have heard from projects that they never would have made it in time without JSF given their scarce resources. Thinking about the bad maintainability of System.out. webapps I am HAPPY using JSF. Wouldn't want to go back to those old times. And using Facelets even the component-writing is really fun. regards Alexander -Original Message- From: taylan saldiray [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 2:25 PM To: MyFaces Discussion; [EMAIL PROTECTED] Subject: Re: New to MyFaces Iordanov, Borislav (GIC) ++ i have worked 6 months on jsf and given it up and wrote my html code direct into the servlet. the reason is: the whole control is under my hand, the rendered code is much simplier, works faster, consumes less space and is more flexible. we have spent one week for binding a table to a model and making it editable and ajax-able wihch took too much time. and when an exception occured, it was hard to detect the reason. one more thing which i disliked about about jsf was a big bug which was solved in newer versions but took much time for us and delayed the project. the reason was a simple synchronization problem where multiple threads accessed an object without synch. On 4/6/07, Werner Punz [EMAIL PROTECTED] wrote: Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
Re: Re: New to MyFaces
The statement that you want to continue to use JSPs, and yet complain that JSF is heavyweight machinery without any substantial benefit seems contradictory to me. In my opinion, backed up by two-years of JSF experience, the biggest flaw of JSF was attempting to use JSPs and all the unnecessary complexity that they bring. What point does it serve to write jsp tag handlers and jsp tld files? Facelets proves that they add no value since you can do the same tasks without them. Why use difficult-to-debug pages-compiled-as-java-code jsp processors when Facelets shows you can get the same functionality and better performance without it? No, facelets is not backwards compatible to JSP, although you can mix JSP and Facelets pages in the same application. And good riddance! Facelets isn't backward compatible to System.out.println() statements either :-) I'm sorry you wasted a lot of time developing jsp tags. I wasted a lot of time developing struts actions, but I'm not all that sad to see them gone. I know that there are those who are working on allowing JSP-compatiblity tags in facelets. Seems like a step backwards to me, but even that will likely happen at some point. JSF is component-based development. It's nice to see that the Java world is finally catching up to what WebObjects provided more than 11 years ago. I hope it doesn't take another 11 to catch up to where WebObjects is now (especially considering that WebObjects hast stagnated the last 5 years, as near as I can tell). My job is to provide solutions to problems, not constantly reinvent the wheel every time I need to display some kind of output. I'm still waiting for the time when I can design a component, drop it in a palette, then drag it out and configure it on my page in a WYSIWYG manner. JSF hasn't reached that point yet, but it's at least a possibility. And facelets allows me to create composite components in less than a minute. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
RE: New to MyFaces
Human beings are very flexible and adaptable, and we would generally get used to any type of crap given enough time ;) How come it took you so long to master JSF, even after reading books and tutorials? Well, I can give you a very simple example: to render an html img tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. Cheers, Bolerio From: Harlan Iverson [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 10:18 AM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: seems that mileage really varies We have heard from projects that they never would have made it in time without JSF given their scarce resources. Thinking about the bad maintainability of System.out. webapps I am HAPPY using JSF. Wouldn't want to go back to those old times. And using Facelets even the component-writing is really fun. regards Alexander I agree with this fully.For me, each project I did in JSF got progressively easier and more pleasurable to deal with. Despite the books and tutorials I read about JSF from the start, the only thing that really made me like it was actually working with it and learning when and how to utilize different parts of the spec. And I mean really LEARNING about it; not hitting a wall and giving up. I cursed and became frustrated, but I kept going. Things seemed impossible at first because I was trying to do them incorrectly. Several subsequent projects taught me about phase listeners, validators, components, render-kits, and when/how to use them together--all things that I knew existed from the start, but not how they really worked in practice. And because of that, with each new project I was able to make better decisions and difficult things became simple. I've done five projects in it, start to finish, and I still probably have things to learn. Harlan
Re: New to MyFaces
On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. How dull and trivial :-) Just change it if it bothers you :-) ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib namespacehttp://java.sun.com/jsf/html/namespace tag tag-nameimg/tag-name component component-typejavax.faces.HtmlGraphicImage/component-type renderer-typejavax.faces.Image/renderer-type /component /tag /facelet-taglib
Re: New to MyFaces
On 4/6/07, Mike Kienenberger [EMAIL PROTECTED] wrote: On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. How dull and trivial :-) Just change it if it bothers you :-) Let me clarify. JSF needs work, but at least complain about something substantial. The lack of page-scoped beans is a good one. The learning time for JSF is comprised primarily of learning the workarounds to the current implementation. It's not that you cannot do something (well, there's likely to be a few things that you cannot do easily), but it's learning how to do it easily. I read through the pre-planning notes for JSF 2.0 last week. It covers almost all of the weaknesses I've seen so far. I think the JSF EG gets it and is going to address them. Not today. Not tomorrow. Probably not even in the next year or two. But eventually. That's the problem with having a Standard rather than an individual project -- it takes time to get it accepted. On the other hand, you'll get buy-in later because it's a standard, so maybe you can avoid framework-of-the-month syndrome down the road. I.e., stop learning and start getting work done.
RE: New to MyFaces
You've missed the point. Unfortunately, I don't know how to explain it more clearly. Sorry ;( -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:30 AM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. How dull and trivial :-) Just change it if it bothers you :-) ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib namespacehttp://java.sun.com/jsf/html/namespace tag tag-nameimg/tag-name component component-typejavax.faces.HtmlGraphicImage/component-type renderer-typejavax.faces.Image/renderer-type /component /tag /facelet-taglib
RE: Re: New to MyFaces
From: Iordanov, Borislav (GIC) [EMAIL PROTECTED] I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). I disagree with this statement. I believe that it says just the opposite. It would have been very easy for the first draft of the JSF specification to be completely focused on a single templating solution (JSP). What I find interesting is that the focus was on building an API that was extensible and not targeted at a specific template technology. I don't think that JSP will go anywhere anytime soon. The JSF/JSP support is much better in JSF 1.2. However, hopefully the work done with Facelets and Shale Clay (see how I got a plug in there) will open the doors for more than one method of creating JSF view's. I'd like to see an option that completly insulates the developer from markup. A design mode that would be like the rich tools for creating fat GUI's with all kinds of reuse through composition options and visual form inheritance. At that point, the ability to plugin multiple render kits would be really handy. Gary -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
Re: New to MyFaces
Then you shouldn't have posted such garbage to begin with. I'm sorry if that sounds harsh, but when you post to a public forum such as this one, you expose yourself to public criticism and review. If you cannot back up your assertions with substance then your assertions are likely to be rejected. I have been through the pain of writing huge servlet-based systems, then JSP, then JSF with JSP, and finally settled happily on JSF with Facelets. This a key element to being a programmer - moving with and keeping up with technology. If you find that this is too burdensome, you may wish to question your chosen profession. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: You've missed the point. Unfortunately, I don't know how to explain it more clearly. Sorry ;( -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:30 AM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. How dull and trivial :-) Just change it if it bothers you :-) ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib namespacehttp://java.sun.com/jsf/html/namespace tag tag-nameimg/tag-name component component-typejavax.faces.HtmlGraphicImage/component-type renderer-typejavax.faces.Image/renderer-type /component /tag /facelet-taglib -- Grant Smith
RE: Re: New to MyFaces
That fact that you can use different view technology is cool, obviously. The fact that you _have_ to use other view technologies than the one supported out of the box is ridiculous (to me obviously also). Again, the point is not that JSF is bad because it has components and a sort of a pluggable architecture (as all decent software does these days), I don't see where I implied that..., the point is that it covers perhaps the most popular area of programming today, with years of experience and tons of other frameworks exploring options and showing what works and what doesn't, and it does with a lot of mistakes. From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:53 AM To: MyFaces Discussion Subject: RE: Re: New to MyFaces From: Iordanov, Borislav (GIC) [EMAIL PROTECTED] I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). I disagree with this statement. I believe that it says just the opposite. It would have been very easy for the first draft of the JSF specification to be completely focused on a single templating solution (JSP). What I find interesting is that the focus was on building an API that was extensible and not targeted at a specific template technology. I don't think that JSP will go anywhere anytime soon. The JSF/JSP support is much better in JSF 1.2. However, hopefully the work done with Facelets and Shale Clay (see how I got a plug in there) will open the doors for more than one method of creating JSF view's. I'd like to see an option that completly insulates the developer from markup. A design mode that would be like the rich tools for creating fat GUI's with all kinds of reuse through composition options and visual form inheritance. At that point, the ability to plugin multiple render kits would be really handy. Gary -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
RE: Re: New to MyFaces
From: Iordanov, Borislav (GIC) [EMAIL PROTECTED] That fact that you can use different view technology is cool, obviously. The fact that you _have_ to use other view technologies than the one supported out of the box is ridiculous (to me obviously also). Again, the point is not that JSF is bad because it has components and a sort of a pluggable architecture (as all decent software does these days), I dont see where I implied that , the point is that it covers perhaps the most popular area of programming today, with years of experience and tons of other frameworks exploring options and showing what works and what doesnt, and it does with a lot of mistakes. Well, you can make a difference if you have the answers. After all, this is open source and these decisions are not made in a vacuum. Gary From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:53 AM To: MyFaces Discussion Subject: RE: Re: New to MyFaces From: Iordanov, Borislav (GIC) [EMAIL PROTECTED] I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). I disagree with this statement. I believe that it says just the opposite. It would have been very easy for the first draft of the JSF specification to be completely focused on a single templating solution (JSP). What I find interesting is that the focus was on building an API that was extensible and not targeted at a specific template technology. I don't think that JSP will go anywhere anytime soon. The JSF/JSP support is much better in JSF 1.2. However, hopefully the work done with Facelets and Shale Clay (see how I got a plug in there) will open the doors for more than one method of creating JSF view's. I'd like to see an option that completly insulates the developer from markup. A design mode that would be like the rich tools for creating fat GUI's with all kinds of reuse through composition options and visual form inheritance. At that point, the ability to plugin multiple render kits would be really handy. Gary -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
problem with forceId
Hi,
Does anyone know how to use the force id in a component?
I looked for an answer but could not see this even mentioned anywhere...
For example I use this tag:
t:inputCalendar id=cal1
renderAsPopup=true
popupDateFormat=MM/dd/
helpText=MM/DD/
renderPopupButtonAsImage =true
onchange=setDateString('cal1','cal2')
forceId=true
size=7
/
And I need id 'cal1' to be forced to true.
When I try and do it with HtmlInputCalendar components I don't have that
option.
HtmlInputCalendar inputCalendar = new HtmlInputCalendar();
String fullSrcId=idPrefix+_+id;
inputCalendar.setId(fullSrcId);
inputCalendar.setRenderAsPopup(true);
inputCalendar.setRenderPopupButtonAsImage(true);
inputCalendar.setSize(7);
inputCalendar.setPopupDateFormat(MM/dd/ );
//FORCE ID???
Yaron
RE: New to MyFaces
The assertion is: beginning with year 2000, every serious programmer knows the value components, modularity, pluggability etc. Also, nearly every serious programmer is perfectly capable of coming up with a UI component framework of their own (be it only because UI component frameworks have been the big hit of object-orientation, they epitomized object-orientation for a long time). There's nothing special about the idea, or the architectural principles. What differentiates then one component framework from another is the ease of use, the intuitiveness, the applicability, the moto that I mentioned simple things should be easy, and complex thing possible etc. In other words, it's the myriad of details one has to pay attention to in order to make the whole feel right. I deliberately chose the most idiotic example of a detail, the incongruous naming of perhaps the least important tag. You would expect 'img' or 'image' because _everybody_ has one or the other, but no it's 'graphicImage'. I just find it funny. Now, two quick substantial issues since you insist (and I'd be more than happy to be proven wrong, I might have misunderstood the spec or myfaces, for that matter): 1) Component state management: all component state needs to be saved, even static state that is defined at compile (or jsp translation time). This is bad architecture. And I hope you are not going to argue that this is fine, because we have so much computing power now ;) 2) No clear definition of development roles within the framework. Being a complex and all encompassing webdev framework, one would expect that it provides well for labor division between programmers and UI designers. But what I see from a UI designer perspective is a new set of tags to learn with not much control over how the output looks, with sometimes unpredictable behavior and no more expressive power than regular HTML. Having an extra layer on top of HTML (the JSF tags) is an opportunity to insulate looks from behavioral logic. JSF didn't cease that opportunity. The components mix appearance and functional attributes. Finally, the whole API is designed around fat classes, not interfaces. This is a serious and in my opinion unnecessary constraints on code that extends JSF in one way or another. Cheers, Bolerio From: Grant Smith [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:59 AM To: MyFaces Discussion Subject: Re: New to MyFaces Then you shouldn't have posted such garbage to begin with. I'm sorry if that sounds harsh, but when you post to a public forum such as this one, you expose yourself to public criticism and review. If you cannot back up your assertions with substance then your assertions are likely to be rejected. I have been through the pain of writing huge servlet-based systems, then JSP, then JSF with JSP, and finally settled happily on JSF with Facelets. This a key element to being a programmer - moving with and keeping up with technology. If you find that this is too burdensome, you may wish to question your chosen profession. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: You've missed the point. Unfortunately, I don't know how to explain it more clearly. Sorry ;( -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] ] Sent: Friday, April 06, 2007 11:30 AM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a serious problem, I'm not joking! Obviously having a component framework, any not completely idiotic component framework, is good. But then the details matter a lot when it comes to usability. How dull and trivial :-) Just change it if it bothers you :-) ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd http://java.sun.com/dtd/facelet-taglib_1_0.dtd facelet-taglib namespacehttp://java.sun.com/jsf/html/namespace tag tag-nameimg/tag-name component component-typejavax.faces.HtmlGraphicImage/component-type renderer-typejavax.faces.Image /renderer-type /component /tag /facelet-taglib -- Grant Smith
RE: Re: New to MyFaces
The point of jsp tag handlers and tld files is that it is a linguistic facility, similar to functions, classes etc in programming languages, that allows one to create abstractions, or coherent sets of such in order to encapsulate and express concisely common tasks in different contexts. I'm curious, what's the equivalent in facelets and why is it better than JSP tags (this is just me trying to avoid reading facelets docs)? I haven't wasted a lot of time developing JSP tags. JSP tags are the greatest invention in the whole Java web server programming world. And the declarative XML-ish syntax isn't so bad either. The parallel with Struts is not appropriate, in my opinion. Struts is a monument of vulgarity. -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:23 AM To: MyFaces Discussion Subject: Re: Re: New to MyFaces The statement that you want to continue to use JSPs, and yet complain that JSF is heavyweight machinery without any substantial benefit seems contradictory to me. In my opinion, backed up by two-years of JSF experience, the biggest flaw of JSF was attempting to use JSPs and all the unnecessary complexity that they bring. What point does it serve to write jsp tag handlers and jsp tld files? Facelets proves that they add no value since you can do the same tasks without them. Why use difficult-to-debug pages-compiled-as-java-code jsp processors when Facelets shows you can get the same functionality and better performance without it? No, facelets is not backwards compatible to JSP, although you can mix JSP and Facelets pages in the same application. And good riddance! Facelets isn't backward compatible to System.out.println() statements either :-) I'm sorry you wasted a lot of time developing jsp tags. I wasted a lot of time developing struts actions, but I'm not all that sad to see them gone. I know that there are those who are working on allowing JSP-compatiblity tags in facelets. Seems like a step backwards to me, but even that will likely happen at some point. JSF is component-based development. It's nice to see that the Java world is finally catching up to what WebObjects provided more than 11 years ago. I hope it doesn't take another 11 to catch up to where WebObjects is now (especially considering that WebObjects hast stagnated the last 5 years, as near as I can tell). My job is to provide solutions to problems, not constantly reinvent the wheel every time I need to display some kind of output. I'm still waiting for the time when I can design a component, drop it in a palette, then drag it out and configure it on my page in a WYSIWYG manner. JSF hasn't reached that point yet, but it's at least a possibility. And facelets allows me to create composite components in less than a minute. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf 1.2 level) and facelets basically do what jsp does. You basically speak about the mixin problems of html and jsf (verbatim tags) this problem is gone in the jsf 1.2 spec, and in facelets, facelets also eliminates problems introduced by jsp...
Re: problem with forceId
Hi Yaron,
did you realy need forceId? I strongly dissuade from using this!
Imho forceId makes more problems than it solves,
and i dont know a case in which it is realy needed.
Anyway:
inputCalendar.getAttributes().put(forceId, cal1);
should do it.
Reagards,
Volker
2007/4/6, Yaron Spektor [EMAIL PROTECTED]:
Hi,
Does anyone know how to use the force id in a component?
I looked for an answer but could not see this even mentioned anywhere...
For example I use this tag:
t:inputCalendar id=cal1
renderAsPopup=true
popupDateFormat=MM/dd/
helpText=MM/DD/
renderPopupButtonAsImage =true
onchange=setDateString('cal1','cal2')
forceId=true
size=7
/
And I need id 'cal1' to be forced to true.
When I try and do it with HtmlInputCalendar components I don't have that
option.
HtmlInputCalendar inputCalendar = new HtmlInputCalendar();
String fullSrcId=idPrefix+_+id;
inputCalendar.setId(fullSrcId);
inputCalendar.setRenderAsPopup(true);
inputCalendar.setRenderPopupButtonAsImage(true);
inputCalendar.setSize(7);
inputCalendar.setPopupDateFormat(MM/dd/ );
//FORCE ID???
Yaron
Re: New to MyFaces
On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: The assertion is: beginning with year 2000, every serious programmer knows the value components, modularity, pluggability etc. Also, nearly every serious programmer is perfectly capable of coming up with a UI component framework of their own (be it only because UI component frameworks have been the big hit of object-orientation, they epitomized object-orientation for a long time). There's nothing special about the idea, or the architectural principles. What differentiates then one component framework from another is the ease of use, the intuitiveness, the applicability, the moto that I mentioned simple things should be easy, and complex thing possible etc. In other words, it's the myriad of details one has to pay attention to in order to make the whole feel right. I deliberately chose the most idiotic example of a detail, the incongruous naming of perhaps the least important tag. You would expect 'img' or 'image' because _*everybody*_ has one or the other, but no it's 'graphicImage'. I just find it funny. And I don't find it a problem to remember that a component called graphicImage will give me a graphic image. If you wanted to, you could just use xhtml, and use facelet's jsfid attribute to connect img to the component. I think your fundamental lack of knowledge of JSF and Facelets is evident in this area, and I fail to see how it qualifies you to be a detractor of the technology. Now, two quick substantial issues since you insist (and I'd be more than happy to be proven wrong, I might have misunderstood the spec or myfaces, for that matter): 1) Component state management: all component state needs to be saved, even static state that is defined at compile (or jsp translation time). This is bad architecture. And I hope you are not going to argue that this is fine, because we have so much computing power now ;) Component state management is well defined in the spec. Myfaces Tomahawk gives you even more power with saveState. There are technologies which fit on top of JSF, like Seam, which give you even more power, like conversational and page scoped components. In any case, your statement is flawed: you do not _have_ to save component state. You _can_, by simply using the Session scope, but that is bad design. 2) No clear definition of development roles within the framework. Being a complex and all encompassing webdev framework, one would expect that it provides well for labor division between programmers and UI designers. But what I see from a UI designer perspective is a new set of tags to learn with not much control over how the output looks, with sometimes unpredictable behavior and no more expressive power than regular HTML. Having an extra layer on top of HTML (the JSF tags) is an opportunity to insulate looks from behavioral logic. JSF didn't cease that opportunity. The components mix appearance and functional attributes. Actually JSF and Facelets allows for reasonable separation of developer roles, as far as this ideal is practical. The UI designers can write pure XHTML, and simply connect to the corresponding beans using jsfid. Way more separation than what JSP gives you... with JSP, your UI folks have to understand JSP.. Finally, the whole API is designed around fat classes, not interfaces. This is a serious and in my opinion unnecessary constraints on code that extends JSF in one way or another. I assume you can back this up, and have extensive experience with extending the API. Please feel free to discuss it in the developer's mailing list (myfaces-dev). Cheers, Bolerio -- *From:* Grant Smith [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 06, 2007 11:59 AM *To:* MyFaces Discussion *Subject:* Re: New to MyFaces Then you shouldn't have posted such garbage to begin with. I'm sorry if that sounds harsh, but when you post to a public forum such as this one, you expose yourself to public criticism and review. If you cannot back up your assertions with substance then your assertions are likely to be rejected. I have been through the pain of writing huge servlet-based systems, then JSP, then JSF with JSP, and finally settled happily on JSF with Facelets. This a key element to being a programmer - moving with and keeping up with technology. If you find that this is too burdensome, you may wish to question your chosen profession. On 4/6/07, *Iordanov, Borislav** (GIC)* [EMAIL PROTECTED] wrote: You've missed the point. Unfortunately, I don't know how to explain it more clearly. Sorry ;( -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] ] Sent: Friday, April 06, 2007 11:30 AM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: tag, you have to use h:graphicImage. A graphic image as opposed to what? To a linux distribution CD image? To a mental image? Naming API design is a
RE: New to MyFaces
From: Grant Smith [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:56 PM To: MyFaces Discussion Subject: Re: New to MyFaces On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: The assertion is: beginning with year 2000, every serious programmer knows the value components, modularity, pluggability etc. Also, nearly every serious programmer is perfectly capable of coming up with a UI component framework of their own (be it only because UI component frameworks have been the big hit of object-orientation, they epitomized object-orientation for a long time). There's nothing special about the idea, or the architectural principles. What differentiates then one component framework from another is the ease of use, the intuitiveness, the applicability, the moto that I mentioned simple things should be easy, and complex thing possible etc. In other words, it's the myriad of details one has to pay attention to in order to make the whole feel right. I deliberately chose the most idiotic example of a detail, the incongruous naming of perhaps the least important tag. You would expect 'img' or 'image' because _everybody_ has one or the other, but no it's 'graphicImage'. I just find it funny. And I don't find it a problem to remember that a component called graphicImage will give me a graphic image. If you wanted to, you could just use xhtml, and use facelet's jsfid attribute to connect img to the component. I think your fundamental lack of knowledge of JSF and Facelets is evident in this area, and I fail to see how it qualifies you to be a detractor of the technology. Hmm..., see it appears I wasted my time trying to explain the point since you are still stuck on the graphicImage example, I regret it now. Now, two quick substantial issues since you insist (and I'd be more than happy to be proven wrong, I might have misunderstood the spec or myfaces, for that matter): 1) Component state management: all component state needs to be saved, even static state that is defined at compile (or jsp translation time). This is bad architecture. And I hope you are not going to argue that this is fine, because we have so much computing power now ;) Component state management is well defined in the spec. Myfaces Tomahawk gives you even more power with saveState. There are technologies which fit on top of JSF, like Seam, which give you even more power, like conversational and page scoped components. In any case, your statement is flawed: you do not _have_ to save component state. You _can_, by simply using the Session scope, but that is bad design. Component state management is well defined, yes, but it is not defined well. Please make an effort to understand what I'm saying if you want to continue this conversation. I'm not speaking about the lack of conversational state management.
Re: New to MyFaces
On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: Now, two quick substantial issues since you insist (and I'd be more than happy to be proven wrong, I might have misunderstood the spec or myfaces, for that matter): 1) Component state management: all component state needs to be saved, even static state that is defined at compile (or jsp translation time). This is bad architecture. And I hope you are not going to argue that this is fine, because we have so much computing power now ;) No. I completely agree. I've brought it up myself. IDEA: client-side state manager that restores majority of saved state from initial tree state http://www.mail-archive.com/dev@myfaces.apache.org/msg19316.html I've even considered creating my own state management (it's pluggable), but I haven't needed it badly enough, yet. However, it's on the potential todo list for JSF 2.0. http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad SubCategory: State Saving - saving page deltas - mostly stateless state saving - Re-do UIComponent State Saving, with a view towards making stateless components the default. 2) No clear definition of development roles within the framework. Being a complex and all encompassing webdev framework, one would expect that it provides well for labor division between programmers and UI designers. But what I see from a UI designer perspective is a new set of tags to learn with not much control over how the output looks, with sometimes unpredictable behavior and no more expressive power than regular HTML. Having an extra layer on top of HTML (the JSF tags) is an opportunity to insulate looks from behavioral logic. JSF didn't cease that opportunity. The components mix appearance and functional attributes. I haven't had an issue with this. There's a clear division of labor where I work, and my html guys haven't had problems working on the page code while I work on the java code. Specifying css styles seems to work ok for them. There's probably a few places where the components need to be improved to have more styles. Some components are simply replaced by raw html (panelGrids with html tables). In fact, I generally get the html pages pre-designed, and I drop in the correct components in the right place before sending them back for touchups. Again the facelets composite component templating makes it all pretty easy. If you don't like how a tag works, replace with with a custom one. Finally, the whole API is designed around fat classes, not interfaces. This is a serious and in my opinion unnecessary constraints on code that extends JSF in one way or another. I can't speak to this since I've had little need to extend the JSF code. What few things I've needed to extend (validators, converters) provided interfaces. The few components I extended extended a base class, which is what I wanted anyway since I was just changing small pieces of behavior.
Re: Re: New to MyFaces
Well, I posted one earlier. I'll post it again. ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib namespacehttp://java.sun.com/jsf/html/namespace tag tag-nameimg/tag-name component component-typejavax.faces.HtmlGraphicImage/component-type renderer-typejavax.faces.Image/renderer-type /component /tag /facelet-taglib This is all that is needed to make a JSF component visible to Facelets. No java classes. No attribute definitions. You simply map a namespace, a tag name, a component, and an optional renderer together. The same is true for validators and converters although what you map together changes. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: The point of jsp tag handlers and tld files is that it is a linguistic facility, similar to functions, classes etc in programming languages, that allows one to create abstractions, or coherent sets of such in order to encapsulate and express concisely common tasks in different contexts. I'm curious, what's the equivalent in facelets and why is it better than JSP tags (this is just me trying to avoid reading facelets docs)? I haven't wasted a lot of time developing JSP tags. JSP tags are the greatest invention in the whole Java web server programming world. And the declarative XML-ish syntax isn't so bad either. The parallel with Struts is not appropriate, in my opinion. Struts is a monument of vulgarity. -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 11:23 AM To: MyFaces Discussion Subject: Re: Re: New to MyFaces The statement that you want to continue to use JSPs, and yet complain that JSF is heavyweight machinery without any substantial benefit seems contradictory to me. In my opinion, backed up by two-years of JSF experience, the biggest flaw of JSF was attempting to use JSPs and all the unnecessary complexity that they bring. What point does it serve to write jsp tag handlers and jsp tld files? Facelets proves that they add no value since you can do the same tasks without them. Why use difficult-to-debug pages-compiled-as-java-code jsp processors when Facelets shows you can get the same functionality and better performance without it? No, facelets is not backwards compatible to JSP, although you can mix JSP and Facelets pages in the same application. And good riddance! Facelets isn't backward compatible to System.out.println() statements either :-) I'm sorry you wasted a lot of time developing jsp tags. I wasted a lot of time developing struts actions, but I'm not all that sad to see them gone. I know that there are those who are working on allowing JSP-compatiblity tags in facelets. Seems like a step backwards to me, but even that will likely happen at some point. JSF is component-based development. It's nice to see that the Java world is finally catching up to what WebObjects provided more than 11 years ago. I hope it doesn't take another 11 to catch up to where WebObjects is now (especially considering that WebObjects hast stagnated the last 5 years, as near as I can tell). My job is to provide solutions to problems, not constantly reinvent the wheel every time I need to display some kind of output. I'm still waiting for the time when I can design a component, drop it in a palette, then drag it out and configure it on my page in a WYSIWYG manner. JSF hasn't reached that point yet, but it's at least a possibility. And facelets allows me to create composite components in less than a minute. On 4/6/07, Iordanov, Borislav (GIC) [EMAIL PROTECTED] wrote: I think the existence of facelets, the motivation behind it, show JSF's failure to deliver on its promise (after so many years!). I haven't looked into Facelets, not that I'm afraid to learn some new view technology. I just don't want to impose this bug fix to people that have already invested time in learning and using JSP pages, with custom tag libraries developed etc (is Facelets backwards compatible with JSP? probably not). -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Friday, April 06, 2007 4:36 AM To: users@myfaces.apache.org Subject: Re: New to MyFaces Iordanov, Borislav (GIC) schrieb: I'm not sure what statistics you are looking for. I haven't done an industry analysis. But in general, JSF is heavyweight machinery without any substantial benefit. Simple things are complicated and complicated things impossible. It was obviously designed by (probably smart, Java knowledgeable) people that have no serious experience with web development. A well-known example is that it still doesn't work well with JSP (a technology for which JSF was designed from the start!) and it probably never will. JSF 1.2 does (myfaces soon will have jsf
Re: Convert, skip validation and update model?
Mike Kienenberger wrote:
What is it that you cannot do with subforms? You mention making
required optional elsewhere -- required=#{bean.isrequirednecessary}
should take care of that..
If you have a specific example, I'm sure you can get help here to find
a solution using subForms.
Here's a the view i'm working on. The input parameters in the form are
generated dynamically. Each input field has a separate required value
which needs to be maintained. During the update form values to model
operation the required attribute should be false for all inputs, but
in other cases the value should be the component's actual required
attribute value. All non-empty form field values that get succesfully
converted should be updated to the model even if there are required
values missing. It should be possible to use value binding for getting
the required attribute value, as you suggested. Since the inputs are
dynamically generated the value bindings would end up looking
something like this:
required=#{bean.isrequirednecessaryMap['fieldid']}
Another approach that comes to mind is using a custom validator for
requiring a field to have a value instead of the required attribute.
When validation is to be skipped for a request, the validator returns
normally for all components, if validation needs to be done it throws
ValidatorException for empty fields. I've been trying out this
approach a bit but for some reason JSF doesn't seem to care about the
ValidatorExceptions that get thrown. It might be that my custom
components don't properly propagate isValid status up the component
tree.
Here's the form:
html
trh:body onload=checkAndOpenPopup();
h:form
h:inputText required=true/
h:commandLink
actionListener=#{reportSelectionHandler.startSelectParameterValues}
h:graphicImage url=foo.gif/
t:updateActionListener
property=#{reportSelection.reportParameterName} value=foo/
/h:commandLink
h:inputText required=false/
h:commandLink
actionListener=#{reportSelectionHandler.startSelectParameterValues}
h:graphicImage url=foo.gif/
t:updateActionListener
property=#{reportSelection.reportParameterName} value=bar/
/h:commandLink
h:commandButton value=get report
actionListener=#{reportSelectionHandler.fetchReport}/
/h:form
h:form id=parameterSelectOpener target=parameterSelect
h:inputHidden value=dummy/
h:commandButton id=parameterSelectOpenerSubmit type=submit
styleClass=hidden-object
action=#{reportSelectionHandler.updateSelections}/
/h:form
/trh:body
script type=text/javascript
function checkAndOpenPopup() {
// if startSelectParameterValues actionListener was succesfully
executed, submit parameterSelectOpener to open a popup window.
// if fetchReport actionListener was succesfully executed, submit a
form which would open up the form in a popup window
}
/script
/html
Re: Convert, skip validation and update model?
Don't take this the wrong way, but you're tell me how you want to
solve the problem instead of telling me what the problem is. Let's
ignore the dynamic part -- it adds a little more complexity, but I
don't think it really will impact how the problem will be solved.
It looks like you're doing a report with dynamic search criteria.
So it's something like this in general
Property Operator Value (x N)
We might have:
h:inputText
value = #{page.prop1} /
h:inputText
value = #{page.op1} /
h:inputText
value = #{page.value1} /
h:inputText
value = #{page.prop2} /
h:inputText
value = #{page.op2} /
h:inputText
value = #{page.value2} /
h:inputText
value = #{page.prop3} /
h:inputText
value = #{page.op3} /
h:inputText
value = #{page.value3} /
h:commandButton action=#{page.search}/
If this is a good description of your situation, fill in the rest of
it. If I'm off-base, please provide an alternate example. I find
it hard to follow if the problem definition is too vague.
On 4/6/07, Marko Asplund [EMAIL PROTECTED] wrote:
Mike Kienenberger wrote:
What is it that you cannot do with subforms? You mention making
required optional elsewhere -- required=#{bean.isrequirednecessary}
should take care of that..
If you have a specific example, I'm sure you can get help here to find
a solution using subForms.
Here's a the view i'm working on. The input parameters in the form are
generated dynamically. Each input field has a separate required value
which needs to be maintained. During the update form values to model
operation the required attribute should be false for all inputs, but
in other cases the value should be the component's actual required
attribute value. All non-empty form field values that get succesfully
converted should be updated to the model even if there are required
values missing. It should be possible to use value binding for getting
the required attribute value, as you suggested. Since the inputs are
dynamically generated the value bindings would end up looking
something like this:
required=#{bean.isrequirednecessaryMap['fieldid']}
Another approach that comes to mind is using a custom validator for
requiring a field to have a value instead of the required attribute.
When validation is to be skipped for a request, the validator returns
normally for all components, if validation needs to be done it throws
ValidatorException for empty fields. I've been trying out this
approach a bit but for some reason JSF doesn't seem to care about the
ValidatorExceptions that get thrown. It might be that my custom
components don't properly propagate isValid status up the component
tree.
Here's the form:
html
trh:body onload=checkAndOpenPopup();
h:form
h:inputText required=true/
h:commandLink
actionListener=#{reportSelectionHandler.startSelectParameterValues}
h:graphicImage url=foo.gif/
t:updateActionListener
property=#{reportSelection.reportParameterName} value=foo/
/h:commandLink
h:inputText required=false/
h:commandLink
actionListener=#{reportSelectionHandler.startSelectParameterValues}
h:graphicImage url=foo.gif/
t:updateActionListener
property=#{reportSelection.reportParameterName} value=bar/
/h:commandLink
h:commandButton value=get report
actionListener=#{reportSelectionHandler.fetchReport}/
/h:form
h:form id=parameterSelectOpener target=parameterSelect
h:inputHidden value=dummy/
h:commandButton id=parameterSelectOpenerSubmit type=submit
styleClass=hidden-object
action=#{reportSelectionHandler.updateSelections}/
/h:form
/trh:body
script type=text/javascript
function checkAndOpenPopup() {
// if startSelectParameterValues actionListener was succesfully
executed, submit parameterSelectOpener to open a popup window.
// if fetchReport actionListener was succesfully executed, submit a
form which would open up the form in a popup window
}
/script
/html
Re: [Tobago] More popup example
Hi Boris, just commited an example for popups inside sheet: http://svn.apache.org/viewvc/myfaces/tobago/trunk/example/demo/src/main/webapp/reference/popupSheet.jsp?view=markup http://svn.apache.org/viewvc/myfaces/tobago/trunk/example/demo/src/main/java/org/apache/myfaces/tobago/example/reference/PopupReferenceController.java?view=markup Regards, Volker 2007/4/6, Boris Kovalenko [EMAIL PROTECTED]: Hello! How to use tc:popup? I looked into sheet example but can't understand how to implement with my code. What I wan to do: I have a sheet where rows are displayed. Each row has a column with tc:button. I want when user press the button the popup open with edit form. Thanks in advance. With respect, Boris
Re: [Tobago] Blocked UI while Exporting to Excel
Hi, Could any one help me in this regard... I need to done this module as soon as possible Any help will be appreciated. Thanks, Vinay On 4/5/07, Vinay Konanki [EMAIL PROTECTED] wrote: Hi All, I got success in generating excel sheet, Thanks for your help, but today i found a problem with in exporting the excel. Problem was: When i'm trying to export the results to excel as there are more than 700 elements to generate, it taking around 5-6 seconds to show window which contains OpenWith SaveAs Cancel buttons. In the mean while when i click on other links in the application its getting blocked UI (i.e non editable UI with progress bar image) for infinite time. So how can i make the screen as non editable when it generating Excel sheet. i.e. i want to show to the user that some process is going on and make the screen non editable i.e user can not make any actions on the screen. Is there any way to make the screen non editable while other process is going on. Please help me in this regard. Any kind of help will be appreciated. I'm running out of time, as my product release is very soon. Thanks, Vinay
Re: [Tobago] Blocked UI while Exporting to Excel
Hi Vinay, you should set transition=false on the button which triggering the download to suppress the transition layer. But there is no way to disable the app while the download is in progress, and enabel again afterwards. Regards, Volker 2007/4/7, Vinay Konanki [EMAIL PROTECTED]: Hi, Could any one help me in this regard... I need to done this module as soon as possible Any help will be appreciated. Thanks, Vinay On 4/5/07, Vinay Konanki [EMAIL PROTECTED] wrote: Hi All, I got success in generating excel sheet, Thanks for your help, but today i found a problem with in exporting the excel. Problem was: When i'm trying to export the results to excel as there are more than 700 elements to generate, it taking around 5-6 seconds to show window which contains OpenWith SaveAs Cancel buttons. In the mean while when i click on other links in the application its getting blocked UI (i.e non editable UI with progress bar image) for infinite time. So how can i make the screen as non editable when it generating Excel sheet. i.e. i want to show to the user that some process is going on and make the screen non editable i.e user can not make any actions on the screen. Is there any way to make the screen non editable while other process is going on. Please help me in this regard. Any kind of help will be appreciated. I'm running out of time, as my product release is very soon. Thanks, Vinay
Re: [Tobago] Blocked UI while Exporting to Excel
You can do as follows: use a button with transition - pressing the button would generate your excel stuff and couse some invisible element to render on the page (with a specific ID) to the page, add a java script using Tobago.afterLoad (perhaps it was called some different way, check...) that checks if the special element was rendered and if so, then it submits action that sends excel stuff to the browser without transition. I have been using this method to submit PDF reports :) regards, michał On 07/04/07, Vinay Konanki [EMAIL PROTECTED] wrote: Hi, Could any one help me in this regard... I need to done this module as soon as possible Any help will be appreciated. Thanks, Vinay On 4/5/07, Vinay Konanki [EMAIL PROTECTED] wrote: Hi All, I got success in generating excel sheet, Thanks for your help, but today i found a problem with in exporting the excel. Problem was: When i'm trying to export the results to excel as there are more than 700 elements to generate, it taking around 5-6 seconds to show window which contains OpenWith SaveAs Cancel buttons. In the mean while when i click on other links in the application its getting blocked UI (i.e non editable UI with progress bar image) for infinite time. So how can i make the screen as non editable when it generating Excel sheet. i.e. i want to show to the user that some process is going on and make the screen non editable i.e user can not make any actions on the screen. Is there any way to make the screen non editable while other process is going on. Please help me in this regard. Any kind of help will be appreciated. I'm running out of time, as my product release is very soon. Thanks, Vinay -- [EMAIL PROTECTED] http://stawicki.jasliska.pl GG: 369 JID: [EMAIL PROTECTED]
Re: [Tobago] More popup example
Hello! Thank You, Volker. Now it is more clear! Volker Weber wrote: Hi Boris, just commited an example for popups inside sheet: http://svn.apache.org/viewvc/myfaces/tobago/trunk/example/demo/src/main/webapp/reference/popupSheet.jsp?view=markup http://svn.apache.org/viewvc/myfaces/tobago/trunk/example/demo/src/main/java/org/apache/myfaces/tobago/example/reference/PopupReferenceController.java?view=markup Regards, Volker With respect, Boris
