Hi
MM >> I had the idea once that one could have an extra embedded style tag which
MM >> goes with each one of the extended components. So you could
embed this tag,
MM >> and set the style attributes there, and the main component would
stay clean.
To be more specific, the idea could be move the code from this:
<t:inputCalendar id="secondOne"
monthYearRowClass="yearMonthHeader" weekRowClass="weekHeader"
popupButtonStyleClass="standard_bold"
currentDayCellClass="currentDayCell"
value="#{calendarBean.secondDate}" renderAsPopup="true"
popupTodayString="#{example_messages['popup_today_string']}"
popupDateFormat="MM/dd/yyyy"
popupWeekString="#{example_messages['popup_week_string']}"
helpText="MM/DD/YYYY"/>
to something like this?
<t:inputCalendar id="secondOne"
value="#{calendarBean.secondDate}" renderAsPopup="true"
popupDateFormat="MM/dd/yyyy"
helpText="MM/DD/YYYY">
<t:styleAttributes monthYearRowClass="yearMonthHeader"
weekRowClass="weekHeader"
popupButtonStyleClass="standard_bold"
currentDayCellClass="currentDayCell"
popupTodayString="#{example_messages['popup_today_string']}"
popupWeekString="#{example_messages['popup_week_string']}" />
</t:inputCalendar>
Or maybe this:
<t:inputCalendar id="secondOne"
value="#{calendarBean.secondDate}" renderAsPopup="true"
popupDateFormat="MM/dd/yyyy"
helpText="MM/DD/YYYY">
<t:styleAttributes
value="#{styleAppScopeBean.calendarPropertyMap}"/>
</t:inputCalendar>
And move the styling attribute from the markup to an application scope
bean like
the proposal in JSF 2.2 related to f:attributes tag?.
I think with just a facelet TagHandler it is possible to do it. Maybe
have a generic style tag and
a special style tag for calendar component, because calendar has a lot
of related attributes.
regards,
Leonardo Uribe
2012/12/19 Cagatay Civici <cagatay.civ...@gmail.com>:
> Hi,
>
> I decided to go with a javascript bundle in PF as calendar is a special
> component in terms or localization and internationalization.
>
> http://code.google.com/p/primefaces/wiki/PrimeFacesLocales
>
> Regards,
>
> Cagatay Civici
> PrimeFaces Lead
> Prime Teknoloji
> www.prime.com.tr
>
> On 19 Ara 2012, at 22:04, Martin Marinschek <mmarinsc...@apache.org> wrote:
>
> Hi guys,
>
>
> Wdyt?
>
> best regards,
>
> Martin
>
>
> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@marathonpm.com> wrote:
>>
>> +1
>>
>> The benefits outweigh the overcrowding of attributes, in my opinion.
>>
>>
>> On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe <lu4...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> I think the proposal looks good, the names used in the properties are ok,
>>> and
>>> there is certainty that the changes are useful.
>>>
>>> regards,
>>>
>>> Leonardo
>>>
>>> 2012/12/19 Werner Punz <werner.p...@gmail.com>:
>>> > Ok just to be more precise, I have integrated the changes now locally,
>>> > but I
>>> > am not committing them yet, because it would mean to introduce another
>>> > set
>>> > of attributes to the Calendar yet.
>>> >
>>> > I just want the opinion whether we should do it.
>>> > Just to give s small description, the attributes would add alt texts
>>> > to the popup calendar and default alt texts are set anyway, the inline
>>> > calendar does not have images hence no alt is needed and possible.
>>> >
>>> > The downside of this is that we add another set of attributes:
>>> >
>>> > popupLeftArrowAlt
>>> > , popupRightArrowAlt
>>> > , popupMonthArrowAlt
>>> > , popupYearArrowAlt
>>> > , popupCloseButtonAlt
>>> > , calendarIconAlt
>>> > , popupWeekOfYearTitle
>>> > , popupWeekOfDateTitle
>>> >
>>> > which is a huge set of new attributes to the already attribute
>>> > overloaded
>>> > calendar.
>>> >
>>> > So what is your opinion guys, shall we add it or not.
>>> > I favor for a +1 here, since accessability is a big plus
>>> > and the new attributes are optional in their usage.
>>> >
>>> > Werner
>>> >
>>> >
>>> >
>>> > Am 19.12.12 11:23, schrieb Werner Punz:
>>> >
>>> >> Mhh shall we integrate this?
>>> >> I personally think it would make sense with some name changes.
>>> >>
>>> >>
>>> >> Werner
>>> >>
>>> >> Am 17.12.12 18:54, schrieb Jon Bionda:
>>> >>>
>>> >>> Sorry for what is likely a breach of protocol. This is a suggestion
>>> >>> on
>>> >>> how to make the Tomahawk Calendar more WCAG compliant. WCAG being a
>>> >>> standard for gauging if browser based interfaces meet accessibility
>>> >>> requirements primarily for disabled users. I joined the list a
>>> >>> while
>>> >>> ago to report an error I found and it was fixed promptly so I
>>> >>> continued
>>> >>> to watch the list and see that you are now preparing the next
>>> >>> Tomahawk
>>> >>> release, so maybe the timing is right.
>>> >>>
>>> >>> We used an older version of Tomahawk (1.0.6) and found the
>>> >>> HtmlInputCalendar component failed the WCAG compliancy tests with
>>> >>> respect to missing some ‘alt’ and ‘title’ attributes on tags
>>> >>> generated
>>> >>> by the calendar component. Some time ago, someone who has since
>>> >>> left
>>> >>> the company, made it mostly compliant by adding the following 8
>>> >>> properties to the HtmlInputCalendar – I didn’t do the compliancy
>>> >>> testing
>>> >>> but understand there are different levels of compliancy and these
>>> >>> missing attributes make it fail at a basic level, so there may be
>>> >>> more
>>> >>> minor compliance issues which is why I can’t say it would be fully
>>> >>> compliant.
>>> >>>
>>> >>> The properties with hopefully self-describing names are:
>>> >>>
>>> >>> calendarIconAlt
>>> >>>
>>> >>> popupLeftArrowAlt
>>> >>>
>>> >>> popupRightArrowAlt
>>> >>>
>>> >>> popupMonthArrowAlt
>>> >>>
>>> >>> popupYearArrowAlt
>>> >>>
>>> >>> popupCloseButtonAlt
>>> >>>
>>> >>> popupWeekOfYearTitle
>>> >>>
>>> >>> popupWeekOfDateTitle
>>> >>>
>>> >>> I’ve looked into forward porting the old changes to the Tomahawk
>>> >>> 1.1.14
>>> >>> code base and have provided the code for adding the changes to the
>>> >>> (org.apache.myfaces.custom.calendar) HtmlInputCalendar and
>>> >>> HtmlCalendarRenderer classes. However, I am having trouble
>>> >>> unravelling
>>> >>> the precise changes that were made to the popcalendar.js file ( they
>>> >>> seemed to have got a newer version of the js file and made the
>>> >>> changes
>>> >>> on it but I can’t figure out which version get got it from, probably
>>> >>> obvious to you guys).
>>> >>>
>>> >>> A related change is also included and was made because part of WCAG
>>> >>> is
>>> >>> supporting screen readers. The text in alt and title attributes
>>> >>> shouldn’t be using short forms of the week days (Sun, Mon, etc.) but
>>> >>> rather their full names (Sunday, Monday, etc.). In the
>>> >>> HtmlCalendarRenderer.getLocalizedLanguageScript() method, I see
>>> >>> where
>>> >>> they created a parallel String[] to weekDays to contain the full week
>>> >>> day names. This is also added to the initData to be accessible in
>>> >>> the
>>> >>> javascript. We only use the calendar in popup mode so no changes
>>> >>> were
>>> >>> made to renderInline() but would expect it would also have to be
>>> >>> modified to do a complete job.
>>> >>>
>>> >>> I zipped up the changes to the 2 java classes mentioned above (they
>>> >>> only
>>> >>> contained changed methods and have “WCAG change” comments identifying
>>> >>> the changes), plus a sample properties file for default values and
>>> >>> our
>>> >>> popcalendar.js file. This last one is where my knowledge is
>>> >>> insufficient to help much, but maybe you will find it useful to see
>>> >>> how
>>> >>> the new properties and full week name array are used. There may be
>>> >>> other changes in the javascript file too as there was an issue
>>> >>> related
>>> >>> to focus.
>>> >>>
>>> >>> Thanks for your time and hope this helps.
>>> >>>
>>> >>> Jon Bionda
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>
>>
>>
>>
>> --
>> Grant Smith - V.P. Information Technology
>> Marathon Computer Systems, LLC.
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
