What this is - I got a list of all the JSF tags that I could see in use or as placeholders. This includes the sakai (sakai) core (f), and the HTML (h), as well as some odds and ends.
Working from a profound ignorance of how they actually work, but with a fairly clear idea of what a useful toolkit should do I tried to find out the following:
So what follows is a little discursive. I have tried to include, for each tag, examples in use, what the tag attributes of significance for the rendering should be for best results, as well as for the simple tags (such as the HTML series) how to use them according to the style guide
The f: (core) tags are a bit of a black box, so not much to say, the h: (html) tags present some difficulties that I try to point out, but the main issue here is the usage. The sakai: tags need revamping or maybe I need a better understanding of that particular library.
Examining all the different UI practives in the new JSF based tools I am struck by the wide variability in how the JSF gets used, what JSF gets used, what the rendered markup looks like, the degree of compliance to the declared doctype and accessibility standards.
This is a long list, but probably better than my first atempt to understand this
What is needed in my view is:
Not sure where used, looks like Samigo makes use of it in
In which case the tag is not complete - witness the <f:verbatim> part.
See below tag
From: sam\webapp\jsf\author\item\itemHeadings.jsp
Could not find any examples. Is this supposed to render header info?
Could not find any examples. The section of a document needs to be the content between one header and the next header (or subheader)
Could not find any examples. The section title needs to a header or subheader
Could not find any examples.
No direct examples. Some workarounds:
From: metaobj\tool\src\webapp\WEB-INF\jsp\editPermissions.jsp
From: scheduler\scheduler-tool\src\webapp\scheduler\main.jsp
Both of these point at a css class that would be well to deprecate in favor of new ones
Used - no impact on rendering.
No examples found - what was it designed to do? Looks like a fieldset.
No examples of it in use - although a lot of tools are doing uploads, each it's own way.
From: preferences\preferences\src\webapp\prefs\noti.jsp
From: presentation\tool\src\webapp\presentation\join.jsp
That seem to render via various adhoc mechanisms like:
preferences\preferences\src\webapp\prefs\prefUpdatedMsg.jsp
What is the difference between <sakai:messages /> and <h:messages>?
It would be excelent for <sakai:messages /> to have modes. Then we could do:
Just demo examples found
Just demo examples found
Issues:
The wrapper used in gradebook is a table, generated via
Whereas it needs to be a block
No examples found. Part of original tag list
No examples found.
No examples found.
No examples found.
No examples found. Not even placeholders.
No examples found. Not even placeholders.
No examples found. Not even placeholders.
No examples found. Not even placeholders.
No examples found. Not even placeholders.
No examples found. Just placeholders. Was this supposed to be the message displayed instead of the toolbar? If so deprecated, now a header, see header
Not sure - how does this relate to the other "Message" tags?
No examples found. Just placeholders.
No examples found. Just placeholders.
No examples found - deprecated? Found use of viewContainer here and
there:
From:preferences\preferences\src\webapp\prefs\refresh.jsp
From:
jsf\widgets\src\java\org\sakaiproject\jsf\renderer\ViewRenderer.java
This renders a block:
From:
jsf\widgets\src\java\org\sakaiproject\jsf\renderer\ViewTitleRenderer.java
This renders a header:
The class attribute is deprecated.
None of these seem to have any rendering consequences - included just in case
The idea here is to identify any problems in the rendering that will need to be addressed in usage or via custom tags (to suplement core h:xxx tags)
The attribute table will treat only the ones with rendering consequences - based on the following assumptions about the response
From: gradebook\tool\src\webapp_common\addAssignment.jsp
But is not <sakai:buttonBar /> and <sakai:buttonBarItem /> taking care of this?
See actionbuttons.html for the extended examples
here is a table| Attribute | Description |
|---|---|
| id | required |
| value | use bundle |
| accesskey | use only if normal serialization (tab order) does not work in this UI |
| alt | required |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| style | use only to override standard rendering |
| styleClass |
thinking is this is where one
overrides the rendering. h:commandButton
can be the child of a parent block that contextually
defines the rendering of all its children - except
for specific children that need to be emphasized
somehow.
See actionButtons |
| tabindex | Use only to override default serialization |
| title | required - use bundle |
From: gradebook\tool\src\webapp_common\assignmentDetails.jsp
From: presentation\tool\src\webapp\presentation\main.jsp
| Attribute | Description |
|---|---|
| id | required |
| accesskey | consult chart... |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is inherited (say: all <a> that are in <th>) - use only if overriding all cases |
| tabindex | use only if normal serialization (tab order) does not work in this ui |
| title | required - use bundle, use "[new window]" if so, differentiate this from all other titles in same view |
Frequent use. Some examples.
From:profile\profile-app\src\webapp\profile\searchResults.jsp
From:syllabus\syllabus-app\src\webapp\syllabus\main.jsp
From:sakai\sam\target\samigo\jsf\author\authorIndex.jsp
| Attribute | Description |
|---|---|
| bgcolor | omit |
| border | set to "0" |
| cellpadding | set to "0" |
| cellspacing | set to "0" |
| columnClasses | open - no class definitions yet |
| footerClass | indeterminate - let the css take care of it via inheritance, unless there is a clear need to make the footer of *this* table be different from the other tables in this same class |
| frame | TODO:not sure what this is meant to accomplish - if the table borders - inherit via css from table class set in the styleClass attribute of dataTable |
| headerClass | Since this applies to all headers of a given table, is of limited utility. Use only if you need to override the inherited header definitions of this particular table's class. |
| rowClasses | Not sure how useful this is. Some possible uses: 1) highlight specific rows? 2) alternate row treatment for readability? In the first case it will look like ",,,,,,,,,,,,highlight,,,,,,,,,,,"; in the second even more exciting |
| rules | indeterminate - let css take care of it via inheritance, unless there is a clear need to make the rules of *this* table be different from the other tables in this same class |
| summary | required |
| styleClass | values for styleClass are (for now): |
| dir, lang, style, title, width |
dir and lang would seem to be best
dealt with in the css as well - set to inherit from a
parent element in most cases (like the <body
/>) and override here if needed. Same for style (use to override). Let width work from the styleClass, unless specifically need override here. title is a bonus. |
| onXXX | events |
| Attribute | Description |
|---|---|
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is - use only if overriding |
| title | optional |
From: help\help-tool\src\webapp\tableOfContents\main.jsp
<h:graphicImage value="../image/topic.gif"/>
From: sakai\profile\profile-app\src\webapp\profile\main.jsp
<h:graphicImage value="#{ProfileTool.profile.pictureUrl}" height="75" width="75" rendered="#{ProfileTool.displayPictureURL}"/>
From: sam\target\samigo\jsf\author\preview_item\AudioRecording.jsp
<h:graphicImage id="image" alt="#{msg.audio_recording}." url="/images/recordresponse.gif" />
| Attribute | Description |
|---|---|
| alt | required |
| dir | set in css of parent block - use here to override |
| height | desirable - specially if large - page and layout load better |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| longdesc | required if image is not iconic and meaning cannot be conveyed in the alt attribute |
| style | use only to override standard rendering |
| styleclass | none if standard rendering is fine (definition of img element) |
| title | desirable |
| width | desirable - page and layout load better |
No rendering
See input text
From:gradebook\tool\target\webapp_dir\sakai-gradebook-tool\assignmentDetails.jsp
<h:inputText id="Score" value="#{scoreRow.score}" size="4" rendered="#{!assignmentDetailsBean.assignment.externallyMaintained}" style="text-align:right;" onkeypress="return submitOnEnter(event, 'gbForm:saveButton');"> <f:convertNumber /> <f:validateDoubleRange minimum="0"/> <f:validator validatorId="org.sakaiproject.gradebook.jsf.validator.ASSIGNMENT_GRADE"/> </h:inputText>
From:help\help-tool\src\webapp\question\display.jsp
<h:outputText value="#{msgs.emailAddress}"/> <h:inputText value="#{QuestionTool.emailAddress}" disabled="true" />
The agreed way to present this element is as part of a label/input pair. See:
Unless the input happens inside of a dataTable, then see:
If required, the rendering should be:
On failed validation the rendering should be:
| Attribute | Description |
|---|---|
| id | Required |
| accesskey | consult chart... |
| required | if required from user... |
| alt | TODO:what possible user agent would need this? |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| maxlength | depends |
| onxxx | events |
| size | required |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is inherited (see wrapper issues below - use only if overriding all cases |
| tabindex | use only if normal serialization (tab order) does not work in this ui |
| title | required - use bundle - provides hover info - futureproof against next version WCAG |
From: help\help-tool\src\webapp\question\display.jsp
<h:outputText value="#{msgs.content}"/> <h:inputTextarea value="#{QuestionTool.content}" cols="45" rows="10" disabled="true" />
From:sakai\sam\target\samigo\jsf\delivery\item\deliverMultipleChoiceSingleCorrect.jsp
<h:outputLabel for="rationale" value="#{msg.rationale}" /> <f:verbatim><br /></f:verbatim> <h:inputTextarea id="rationale" value="#{question.rationale}" rows="5" cols="40" disabled="#{delivery.previewMode eq 'true'}" />
The agreed way to present this element is as part of a label/input pair. See:
If required, the rendering should be:
On failed validation the rendering should be:
| Attribute | Description |
|---|---|
| id | required |
| accesskey | consult chart... |
| cols | TODO:determine standard |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| onxxx | events |
| rows | TODO:determine standard |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is inherited (see wrapper issues above - use only if overriding all cases |
| tabindex | use only if normal serialization (tab order) does not work in this ui |
| title | required - use bundle -provides hover info - futureproof against next version WCAG |
From: gradebook\tool\src\webapp_common\assignmentDetails.jsp
<h:column> <h:message for="Score" styleClass="validationEmbedded"/> </h:column>
From:sakai\sam\target\samigo\jsf\author\editPart.jsp
<h:message for="numSelected" styleClass="validate"/>
From:scheduler\scheduler-tool\src\webapp\scheduler\create_job.jsp
<h:inputText id="job_name" value="#{schedulerTool.jobName}" required="true" validator="#{schedulerTool.validateJobName}"/> <h:message for="job_name" styleClass="chefRequiredInline"/>
The recommendations for messages are as follows (there is no clear 1X1 correspondence to the types given in attributes for h:message) - this needs to be figured out.
| Attribute | Description |
|---|---|
| for | TODO:what are the implications of this? |
| id | TODO:needed? |
| showDetail | TODO:what are the implications of this? |
| showSummary | TODO:what are the implications of this? |
| errorClass | TODO:match ERROR with style class |
| errorStyle | Only to override errorClass |
| fatalClass | TODO:match FATAL with style class |
| fatalStyle | Only to override fatalClass |
| infoClass | TODO:match INFO with style class, first glance this should be "infoMessage" |
| infoStyle | Only to override infoClass |
| style | Only to override styleClass |
| styleClass | TODO: generalized styleClass that is overridden by message type styleClasses? |
| title | Can't see the desirability of this |
| tooltip | Can't see the desirability of this |
| warnClass | TODO:match FATAL with style class |
Same as message above - Do not really understand all the implications - I do think that we should not use the table value for the layout attribute
Looks like just a string?
See h:inputText above
See h:commandLink above
Nothing to report
See h:dataTable above - avoid use for layout
I think I understand this - not much to say
From:profile\profile-app\src\webapp\profile\edit.jsp
<h:selectBooleanCheckbox title= "Hide my Personal Information" value="#{ProfileTool.profile.hidePrivateInfo}" /> <h:outputText value="Hide only my Personal Information" style="font-size: 11;" />
From:syllabus\syllabus-app\src\webapp\syllabus\main_edit.jsp
<h:column rendered="#{! SyllabusTool.displayNoEntryMsg}"> <f:facet name="header"> <h:outputText value="Remove"/> </f:facet> <h:selectBooleanCheckbox value="#{eachEntry.selected}"/> </h:column>
From:gradebook\tool\src\webapp_common\gradeOptions.jsp
<h:selectBooleanCheckbox id="displayAssignmentGrades" value="#{feedbackOptionsBean.localGradebook.assignmentsDisplayed}" onkeypress="return submitOnEnter(event, 'gbForm:saveButton');"/> <h:outputLabel for="displayAssignmentGrades" value="#{msgs.feedback_options_grade_display_assignment_grades}" />
The agreed way to present this element is as part of a label/input pair. See:
Unless the input happens inside of a dataTable, then see:
If required, the rendering should be:
On failed validation the rendering should be:
Note: above deals with input[type="radio"] but is all the same.
| Attribute | Description |
|---|---|
| Id | required |
| accesskey | consult chart... |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| onxxx | events |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is inherited (see wrapper issues above - use only if overriding all cases |
| tabindex | use only if normal serialization (tab order) does not work in this ui |
| title | required - use bundle -provides hover info - futureproof against next version WCAG |
Note: the rendering of this widget is very problematic - a table, each cell containing a label wrapping an input. Whereas this is all correct, adds unnecessary markup. The label wrapping the input is unconventional but correct as well. Of course - do not need for and id attributes in this case. Or do we? TODO:check if so.
<table> <tr> <td> <label for="jsftags:cars1"> <input name="jsftags:cars1" value="accord" type="checkbox" id="jsftags:cars1"> Honda Accord </label> </td> .............. </tr> </table>
| Attribute | Description |
|---|---|
| id | required |
| accesskey | consult chart... |
| border | set to 0" |
| dir | set in attributes of a parent block and addressed in the css - use here to override |
| disabledClass | TODO:what would this be other than the default rendering? |
| enabledClass | TODO:what would this be other than the default rendering? |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| layout | Really really wish the options for this attribute did not result both in tables |
| onxxx | events |
| style | use only to override standard rendering |
| styleClass | TODO:what would this be? |
| tabindex | use only if normal serialization (tab order) does not work in this ui |
| title | required - use bundle -provides hover info - futureproof against next version WCAG |
Same as h:selectOneListbox below, + the many and size options
Same as h:selectManyListbox? Can't tell the difference in the rendering
Seems to be missing the <optgroup /> possibility
The agreed way to present this element is as part of a label/input pair. See:
Unless the input happens inside of a dataTable, then see:
actionTable (same treatment as the input[type=text])
If required, the rendering should be:
inputTextRequired (same treatment as the input[type=text])
On failed validation the rendering should be:
inputTextValidationError (same treatment as the input[type=text])
| Attribute | Description |
|---|---|
| accesskey | consult chart... |
| dir | set in css of parent block - use here to override |
| lang | set in attributes of a parent block and addressed in the css - use here to override |
| disabledClass | TODO:what would this be other than the default rendering? |
| enabledClass | TODO:what would this be other than the default rendering? |
| onxxxx | events |
| size | TODO:not a valid attribute for a single select <select /> - Spec says: "Number of available options to be shown at all times. If not specified, all available options are shown." Spec is confused? |
| style | use only to override standard rendering |
| styleClass | none if standard rendering is fine, none if specific rendering is inherited (see wrapper issues above - use only if overriding all cases |
| Tabindex | use only if normal serialization (tab order) does not work in this ui |
| Title | required - use bundle - provides hover info - futureproof against next version WCAG |
Same as h:selectOneListbox? Can't tell the difference in the rendering
Same issues as in h:selectBooleanCheckbox above
These are things I have found in use