Hi
I can dedicate some time to this issue. It is an interesting thing to
do, and I have enough knowledge in JSF and Trinidad codebase. Anyway,
it could be good if you can review the code.
It seems we need to extend -tr-property-ref to allow a syntax like this:
.somecssclass {
border: 1px solid #aed0ea;
}
border-color: -tr-property-ref(".somecssclass", "border", "3");
To retrieve for example, in this case, only the color of the border
and so on. Any idea about how to specify that?.
Maybe we should more this discussion to dev list.
regards,
Leonardo Uribe
2012/6/21 Scott O'Bryan <darkar...@gmail.com>:
> Yeah, something like this MIGHT work in the case where the styles
> 'fit' the current DOM. You're right that there is a lot of
> flexibility there.
>
> In any case, I think this approach (integrating theme-roller) has the
> most merit because, instead of rewriting Trinidad's JS, we simply
> allow JQuery and Trinidad to co-exist under a common look and feel. :D
>
> Now for the $1,000,000 question. Who wants to do it?
>
> Scott
>
> Sent from my iPhone
>
> On Jun 21, 2012, at 3:25 AM, Leonardo Uribe <lu4...@gmail.com> wrote:
>
>> Hi
>>
>> Going back to TRINIDAD-2120, I have seen that is not really necessary to
>> create a parser. Instead we can use trinidad skinning code to do that. For
>> example:
>>
>> .AFDarkBackground:alias {
>> background-color: -tr-property-ref(".ui-widget-header","color");
>> }
>>
>> .AFDarkAccentBackground:alias {
>> -tr-rule-ref: selector(".ui-widget-content");
>> }
>>
>> Trinidad skinning is already able to read any css and use it to derive
>> another skin.
>>
>> I also tried to override a rendered using this hack:
>>
>> http://matthiaswessendorf.wordpress.com/2008/02/20/extending-trinidads-default-renderers/
>>
>> The idea was override <tr:document> to include jQuery script. It works.
>>
>> We could do a "mixed" strategy. Create a custom RenderKit for trinidad,
>> but only override some specific renderers. Also, create a "template" theme
>> like is proposed in TRINIDAD-2120 and add it as a skin addition. For
>> example:
>>
>> <skin>
>> <id>cupertino.desktop</id>
>> <family>cupertino</family>
>> <render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
>>
>> <style-sheet-name>skins/themeroller/cupertino/jquery-ui-1.8.21.custom.css</style-sheet-name>
>> </skin>
>> <skin-addition>
>> <skin-id>cupertino.desktop</skin-id>
>>
>> <style-sheet-name>skins/themeroller/trinidad-theme.css</style-sheet-name>
>> </skin-addition>
>> <skin-addition>
>> <skin-id>cupertino.desktop</skin-id>
>> <style-sheet-name>skins/themeroller/layout.css</style-sheet-name>
>> </skin-addition>
>>
>> In that way, you can still use ThemeRoller app / jQuery UI CSS
>> Framework to create
>> your own skin, and apply it transparently in trinidad.
>>
>> So, our first task would be try apply a themeroller skin into
>> Trinidad, without change any renderer.
>> Then, optionally we can try to change the component renderers to use
>> some jquery widgets.
>>
>> WDYT? Suggestions are welcome.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2012/6/21 Leonardo Uribe <lu4...@gmail.com>:
>>> Hi
>>>
>>> I see. We could try that. What I like about that idea is that it
>>> reduce the amount of files to be created, and at the end sounds less
>>> restrictive and go aligned with the efforts in TRINIDAD-2120.
>>>
>>> Also, here we have the whole point of the discussion. If we can take
>>> some skins and include them in Trinidad, do we really need jQuery
>>> inside Trinidad? For example, Trinidad casablanca skin look very good,
>>> and it does not suppose use any additional js at all. Note that does
>>> not means you cannot use jQuery together with Trinidad, but if you
>>> have a way to convert ThemeRoller skins into Trinidad, the code
>>> created with jQuery UI could be mixed in a transparent way with
>>> Trinidad, because the L & F will look the same. At the end, we could
>>> change the question about use jQuery or not into this question: How we
>>> can use jQuery UI and create custom widgets and have the same skin
>>> applied when using JSF + Trinidad?.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2012/6/20 Scott O'Bryan <darkar...@gmail.com>:
>>>> Right. That's kind of why I suggested a style sheet parser. The idea
>>>> is to take some of the styles generated by file roller (the ones that
>>>> we can) and use them to generate a Trinidad skinning file.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jun 20, 2012, at 11:42 AM, Leonardo Uribe <lu4...@gmail.com> wrote:
>>>>
>>>>> Hi Walter
>>>>>
>>>>> Yes, I know that. There is no stopper that could avoid us to use the
>>>>> datepicker widget, but note to limit the scope of the work, it sounds
>>>>> more convenient to take some styles from that widget and make them
>>>>> "fit" in the current implementation. It will take less time and
>>>>> effort. Later, we could try to see if we can use the widget.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2012/6/20 Walter Mourão <walter.mou...@gmail.com>:
>>>>>> Hi Leonard,
>>>>>> I did not understand very well.
>>>>>>
>>>>>> Just take what's useful of
>>>>>>> jQuery (css stuff) and forget about the rest.
>>>>>>>
>>>>>>
>>>>>> How about the components ? Do you mean we can 'decorate' the inputs and
>>>>>> other things using only the CSS ? The
>>>>>> datepicker<http://jqueryui.com/demos/datepicker/>,
>>>>>> for example, needs some javascript..
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Walter Mourão
>>>>>> http://waltermourao.com.br
>>>>>> http://arcadian.com.br
>>>>>> http://oriens.com.br
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 20, 2012 at 12:58 PM, Leonardo Uribe <lu4...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I think it is possible, but note Trinidad skins has a lot more
>>>>>>> details. In theory
>>>>>>> you could extract the meta-info of the skin and try to generate a
>>>>>>> trinidad
>>>>>>> skin,
>>>>>>> from a parametrized template, but it is necessary to adjust tha
>>>>>>> template "at hand".
>>>>>>> For example, I tried to take casablanca skin, because its selectors are
>>>>>>> more
>>>>>>> simple to understand.
>>>>>>>
>>>>>>> The idea about create a custom RenderKit from scratch sounds like a lot
>>>>>>> of
>>>>>>> work,
>>>>>>> but if we make some simplifications it could be possible. After all,
>>>>>>> it should be
>>>>>>> possible to reuse code from other renderkits. What I like about this
>>>>>>> is we can do
>>>>>>> it without change any trinidad internals at all. Just take what's
>>>>>>> useful of
>>>>>>> jQuery (css stuff) and forget about the rest.
>>>>>>>
>>>>>>> Sounds like something doable in a reasonable amount of time, and maybe
>>>>>>> it
>>>>>>> is
>>>>>>> something with high priority, given the amount of people interested.
>>>>>>> After all, for
>>>>>>> now MyFaces Core is in good shape, and there is some time until JSF 2.2.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>> 2012/6/19 Scott O'Bryan <darkar...@gmail.com>:
>>>>>>>> +1. Theme roller would be cool. The problem is the current skinning
>>>>>>>> selectors. I'm wondering if themeroller themes couldn't be parsed
>>>>>>>> into a skin.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jun 19, 2012, at 8:08 AM, Leonardo Uribe <lu4...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Interesting question. In my opinion, the most interesting part to use
>>>>>>>>> from jQuery is its jQuery UI CSS Framework. Why? because defining some
>>>>>>>>> small set of selectors and a "standard" html structure to apply them,
>>>>>>>>> you can create a custom skin using ThemeRoller application. I tried to
>>>>>>>>> do something as a "proof of concept" in
>>>>>>>>> https://issues.apache.org/jira/browse/TRINIDAD-2120 , but after some
>>>>>>>>> time I found that anyway it is necessary to create a whole RenderKit
>>>>>>>>> that can fit better with jQuery UI. In that way, some good features
>>>>>>>>> Trinidad already has will be lost, because jQuery UI is the one who
>>>>>>>>> impose the restrictions. At the end you can't have everything. In my
>>>>>>>>> opinion, I would take only jQuery UI CSS Framework, even if that means
>>>>>>>>> lose some functionality in that mode. Change Trinidad internals to use
>>>>>>>>> jQuery is overkill.
>>>>>>>>>
>>>>>>>>> Suggestions are welcome.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>> Leonardo Uribe
>>>>>>>>>
>>>>>>>>> 2012/6/19 <siyaphakama.sos...@accenture.com>:
>>>>>>>>>> Hello Everyone
>>>>>>>>>>
>>>>>>>>>> I am a JSF and Trinidad Newbie, I just joined a project at work where
>>>>>>> it's going to be using Trinidad. I was assigned a task to design some
>>>>>>> forms
>>>>>>> and so far I haven't had the best experience with Trinidad, The Date
>>>>>>> Input
>>>>>>> keeps giving me errors even though I use the same code as the Trinidad
>>>>>>> Showcase(
>>>>>>> http://example.irian.at/trinidad-components-showcase-2012061903/faces/pages/demoStart.xhtml).
>>>>>>> The Tabbed Panel is not rendering but its showing the content. My
>>>>>>> conclusion is I'm having issues with components that use JavaScript even
>>>>>>> the Tree and there are no errors showing on Firebug. Please Help, I'm
>>>>>>> not
>>>>>>> sure where I'm going wrong.
>>>>>>>>>>
>>>>>>>>>> My Opinion:
>>>>>>>>>>
>>>>>>>>>> Trinidad looks like a great component library for JSF, but I think
>>>>>>>>>> its
>>>>>>> documentation can use some upgrade, it's confusing for a newbie like me,
>>>>>>> There is no simple starting point, e.g. a basic guide, where it going to
>>>>>>> show basic steps to follow, like Primefaces Guide(
>>>>>>> http://primefaces.org/documentation.html). When I played around with
>>>>>>> Primefaces everything was straightforward but I wish to utilize
>>>>>>> Trinidad.
>>>>>>>>>>
>>>>>>>>>> Missing Components:
>>>>>>>>>>
>>>>>>>>>> Some will agree with me when I say I think a time picker needs to be
>>>>>>> added to the Trinidad Library.
>>>>>>>>>> An improved Date Picker would be a plus, Compare the JQuery Date
>>>>>>> picker and the Trinidad Date Picker.
>>>>>>>>>>
>>>>>>>>>> Just My Opition
>>>>>>>>>>
>>>>>>>>>> Thank You
>>>>>>>>>>
>>>>>>>>>> Siya
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ________________________________
>>>>>>>>>> Subject to local law, communications with Accenture and its
>>>>>>>>>> affiliates
>>>>>>> including telephone calls and emails (including content), may be
>>>>>>> monitored
>>>>>>> by our systems for the purposes of security and the assessment of
>>>>>>> internal
>>>>>>> compliance with Accenture policy.
>>>>>>>>>>
>>>>>>> ______________________________________________________________________________________
>>>>>>>>>>
>>>>>>>>>> www.accenture.com
>>>>>>>>>>
>>>>>>>
