[jira] Created: (TRINIDAD-1106) tr:messages inside tr:showdetail generates js error
tr:messages inside tr:showdetail generates js error --- Key: TRINIDAD-1106 URL: https://issues.apache.org/jira/browse/TRINIDAD-1106 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.8-core, 1.0.8-core Reporter: Cristi Toth Assignee: Cristi Toth Priority: Minor if there is a tr:messages inside a tr:showDetail if you expand, collapse and expand again, you'll get a js error -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1106) tr:messages inside tr:showdetail generates js error
[ https://issues.apache.org/jira/browse/TRINIDAD-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth resolved TRINIDAD-1106. --- Resolution: Fixed Fix Version/s: 1.2.9-core 1.0.9-core tr:messages inside tr:showdetail generates js error --- Key: TRINIDAD-1106 URL: https://issues.apache.org/jira/browse/TRINIDAD-1106 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Cristi Toth Assignee: Cristi Toth Priority: Minor Fix For: 1.0.9-core, 1.2.9-core if there is a tr:messages inside a tr:showDetail if you expand, collapse and expand again, you'll get a js error -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [trinidad] release? I need help...
Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
Hi Blake! On Thu, Apr 17, 2008 at 11:44 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Cristi Toth said the following On 4/17/2008 2:25 PM PT: On Thu, Apr 17, 2008 at 11:15 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Cristi Toth said the following On 4/17/2008 2:00 PM PT Does anybody KNOW how the browsers express their version exactly? Because TrinidadAgent currently only has majorVersion and agentVersion (the latter being an unparsed string). I will have to parse that agentVersion to also get out the minor version. Does anybody know why this wasn't done initially? (any reason like too different between the browsers?) I can't remember why I wrote the code the way I did 12 years ago, but assuming that I was lazy and didn't think that it probably mattered that much at the time is probably a good bet. :) I assume you can't donate prematurely those regex, right? I'm sure we can. Matthias, can you give them to Christi. They are in AdfAgent.getAgent(). -- Blake Can we hurry up this pls. Matthias is planning a release and it would be nice to have this feature the right way in there. -- Blake Sullivan 8 is promoted to 8.0 and since max- means less-than-or-equal-to:max-version:8 means version = 8.0 == true -- Blake Sullivan -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [trinidad] release? I need help...
On Mon, May 5, 2008 at 10:46 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Cristi Toth said the following On 5/5/2008 1:32 PM PT: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Christi, So, is the implementation using the Media Query done and all we are waiting for is the regex? Have you tested how this implementation works with the CSS caching. Jeanne Waldman and I looked at the code, and it looks like it might be fine, but its one of those things where it would be best to step through the code to make sure. I would expect that one upshot of the easiest possible implementation is that we would end up caching a version of the CSS for every possible combination of agent version and agent that we see (as opposed to one per major agent version as we do now). -- Blake Sullivan Sorry, no changes implemented yet, but I plan to go hard on it asap and I don't expect to take me too much time, so it would be nice to have those regex at hand when I start working on it. Yep easiest would be to just cache one CSS file per agent +full version. I assume that having one cached CSS file per agent version wouldn't be much of a problem on a server. Otherwise we would have to have version intervals, which doesn't seem necessary to me. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers -- Cristi Toth - Codebeat www.codebeat.ro
Re: [trinidad] release? I need help...
On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Easy enough for me since I'm in the middle of something else right now.. Cristi, can you ping me on this thread when TRINIDAD-799 is done and committed? I'll try to monitor it, but just in case I miss it... :) I'll try not to forget ;) Andrew Robinson wrote: +1 for the release to wait on TRINIDAD-799 On Mon, May 5, 2008 at 2:32 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
) is potentially confusing due to inconsistency
3) might not be immediately obvious and could
theoretically have
precision problems
4) is not immediately obvious either but incredibly flexible
I vote for 3) since it gets the job done and doesn't
preclude doing
more later.
-- Blake Sullivan
Andrew Robinson said the following On 4/17/2008 11:53 AM
PT:
http://www.w3.org/TR/REC-CSS2/media.html
@import url(loudvoice.css) aural;
so here are multiple groups of characters that show
that spaces
are
acceptable (import url and aural keywords in one bunch)
url(loudvoice.css)
shows that parenthesis with at least one argument is
acceptable
@media screen, print {
Shown that a comma separated list, unlike normal CSS
selectors
applies
to the whole @ (meaning that it wasn't @meda screen, @media
print)
From css3 (http://www.w3.org/TR/css3-reader/):
@import my-print-style.css print;
here, a quoted string is permissible (goes with the
url values in
CSS rules)
?xml-stylesheet href=style1.css type=text/css
media=screen and (color) and (max-width: 400px?
?xml-stylesheet href=style2.css type=text/css
media=reader and (max-device-ratio: 1/1)?
Hmmm interesting, but do we want to reuse
something that
relates
to CSS but is not in a CSS file?
@media reader and (grid: 0)
Ah, now we are talking. This looks like what Blake was
referring
to
From http://www.css3.info/preview/media-queries/:
@media all and (min-width: 640px) {
Even better, showing an all keyword and having
normal CSS
properties in parens.
http://www.css3.info/preview/attribute-selectors/:
Do we dare take RegExp like syntax from attr.
selectors and apply
them
to @agent rules?
So I can see Blake's suggestion being backed by these,
but IMO
max-version-less-than:8 is too long to remember.
Perhaps just:
IE 5.5 or greater:
@agent ie and (min-version: 5.5)
IE 5.0 or greater:
@agent ie and (min-version: 5)
IE = 5.0 and 6.0:
@agent ie and (version: 5)
or (I like this one less):
@agent ie and (major-version: 5)
IE = 6.0:
@agent ie and (max-version: 6)
IE 6:
@agent ie and (max-version: 5.9)
IE = 6.0 and 8.0:
@agent ie and (min-version: 6) and (max-version: 7.9)
same as:
@agent ie and (min-version: 6) and (max-version: 7)
IE = 6.0 and = 8.0:
@agent ie and (min-version: 6) and (max-version: 8.0)
IE = 6.0 and = 8.x:
@agent ie and (min-version: 6) and (max-version: 8)
So x.y (ie 5.5) means precisely that, no vagueness and
x (ie 6)
means
major version x regardless of minor version. If it is too hard
to
parse the decimal and remember it,
max-major-version,
min-major-version and major-version could be used
for integer
only
comparison with the major version and max-version,
min-version
and
version could be used for full major.minor comparison.
I think using something like 7.9 or 7.99 could
theoretically be
used
for less than but not equal to. I think the fewer number of
keywords
the clearer it will be to use. Just my opinion.
Just adding some thoughts to chew on since concrete
ideas were
asked for.
-Andrew
On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth
[EMAIL PROTECTED] wrote:
Hi guys
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
: 640px) {
Even better, showing an all keyword and having normal CSS
properties in parens.
http://www.css3.info/preview/attribute-selectors/:
Do we dare take RegExp like syntax from attr. selectors and apply
them
to @agent rules?
So I can see Blake's suggestion being backed by these, but IMO
max-version-less-than:8 is too long to remember.
Perhaps just:
IE 5.5 or greater:
@agent ie and (min-version: 5.5)
IE 5.0 or greater:
@agent ie and (min-version: 5)
IE = 5.0 and 6.0:
@agent ie and (version: 5)
or (I like this one less):
@agent ie and (major-version: 5)
IE = 6.0:
@agent ie and (max-version: 6)
IE 6:
@agent ie and (max-version: 5.9)
IE = 6.0 and 8.0:
@agent ie and (min-version: 6) and (max-version: 7.9)
same as:
@agent ie and (min-version: 6) and (max-version: 7)
IE = 6.0 and = 8.0:
@agent ie and (min-version: 6) and (max-version: 8.0)
IE = 6.0 and = 8.x:
@agent ie and (min-version: 6) and (max-version: 8)
So x.y (ie 5.5) means precisely that, no vagueness and x (ie 6)
means
major version x regardless of minor version. If it is too hard to
parse the decimal and remember it, max-major-version,
min-major-version and major-version could be used for integer
only
comparison with the major version and max-version, min-version
and
version could be used for full major.minor comparison.
I think using something like 7.9 or 7.99 could theoretically be
used
for less than but not equal to. I think the fewer number of
keywords
the clearer it will be to use. Just my opinion.
Just adding some thoughts to chew on since concrete ideas were
asked for.
-Andrew
On Thu, Apr 17, 2008 at 12:26 PM, Cristi Toth
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi guys,
You're right, I should have discussed the format before
committing it.
I started fixing the issue using the format that was specified
there...
(there weren't to many comments on that issue btw...)
During I was fixing it, I noticed that XSS suppported multiple
versions,
so I adapted what was suggested on the issue to support that
too.
Anyway, lets get this subject out in a new thread
and stick here to discussing the format.
Guys, those of you that suggested some general guidelines, they
all sound
good,
but please try to think of some concrete format that comply with
those
guidelines.
If we decide a final format and implement it until its get
released, then no
big harm done.
So please be constructive ;)
Thanks for any feedback!
cheers,
--
Cristi Toth
-
Codebeatwww.codebeat.ro
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
:) yep, I forgot about the and
is or valid in those CSS rules?
On Sat, Apr 19, 2008 at 6:44 PM, Blake Sullivan [EMAIL PROTECTED]
wrote:
Cristi Toth said the following On 4/19/2008 3:51 AM PT:
or @agent ie and (version:6) and (version:8)
This rule would never be true because it is asserting that the agent must
match IE and the version must match both 6.* and 8.*
-- Blake Sullivan
On Sat, Apr 19, 2008 at 1:31 AM, Blake Sullivan [EMAIL PROTECTED]
wrote:
Glauco P. Gomes said the following On 4/18/2008 4:28 PM PT:
I think that I'm not expressed correctly, what I wanted to say was not
sequencial major versions.
Eg.:
@agent ie and (version: 6 and 8) {
/* styles for all 6.*, and 8.* versions of the IE agent versions */
}
@agent ie and (version:6), ie and (version:8)
-- Blake Sullivan
Or this doesn't make sense?
Glauco P. Gomes
Matt Cooper escreveu:
It does:
@agent ie and (min-version:5) and (max-version:7) {
/* styles for all 5.*, 6.*, and 7.* versions of the IE agent versions */
}
Regards,
Matt
On Fri, Apr 18, 2008 at 5:02 PM, Glauco P. Gomes[EMAIL PROTECTED] [EMAIL
PROTECTED] wrote:
+1 if this includes multiple major versions (5, 6, 7)
Glauco P. Gomes
Blake Sullivan escreveu:
Glauco P. Gomes said the following On 4/18/2008 3:45 PM PT:
I like this option, but what hapens if the user wants to match the
version 5? (Only 5, not 5.5)
@agent ie and (version:5.0)
That will match version 5.0.* but that's probably what he wants
-- Blake Sullivan
Glauco P. Gomes
Blake Sullivan escreveu:
OK, how about
option 5) the version feature is a String that matches the native
major.minor.whatever format of the browser's engine. If the browser's
engine uses non . for separating versions, . is used instead.
For matches, the * character is allowed in any version section.
For comparisons, the * is always a valid match regardless of , ,
or = comparison
For comparisons where the comparison side contains fewer version
sections than the actual browser version, the comparison side is padded
with
* version sections and the comparison occurs as above.
For comparisons where the comparison side contains more version
sections than the actual browser version, the browser version is padded
with
0 version sections and the comparison occurs as above.
// user wants to match IE 5, actual browser version ie 5.5
@agent ie and (version:5)
matches because version:5 expands to version 5.* and 5.* matches 5.5
@agent ie and (min-version:5)
matches because version:5 expands to version 5.* and 5.* 5.5 = true
@agent ie and (max-version:5)
matches because version:5 expands to version 5.* and 5.* 5.5 = true
// actual browser version gecko 1.9
@agent gecko and (min-version:1.9.2)
does not match because the browser version 1.9 expands to 1.9.0 and
1.9.2 is than 1.9.0
// actual browser version gecko 1.9
@agent gecko and (min-version:1.9.*)
matches because the browser version 1.9 expands to 1.9.0 and 1.9.* ==
1.9.0
-- Blake Sullivan
Blake Sullivan said the following On 4/17/2008 12:31 PM PT:
If we agree that we like the we like the media query syntax and that
the only issue is how to handle less than (as opposed the =) for the
max-version, then we can just collect up the proposals and pick one:
1) The verbose and explicit (max-version-less-than:8).
2) Define that for the version feature, max-version means not =.
Inconsistent with other uses of max (max-version:8)
3) Let the skinning author provide enough precision to avoid the
need to distinguish between 8 and = a number that apporaches 8
(max-version:7.99)
4) Add an operator suffix (max-version-lt:8)
1) is gross
2) is potentially confusing due to inconsistency
3) might not be immediately obvious and could theoretically have
precision problems
4) is not immediately obvious either but incredibly flexible
I vote for 3) since it gets the job done and doesn't preclude doing
more later.
-- Blake Sullivan
Andrew Robinson said the following On 4/17/2008 11:53 AM PT:
http://www.w3.org/TR/REC-CSS2/media.html
@import url(loudvoice.css) aural;
so here are multiple groups of characters that show that spaces
are
acceptable (import url and aural keywords in one bunch)
url(loudvoice.css)
shows that parenthesis with at least one argument is acceptable
@media screen, print {
Shown that a comma separated list, unlike normal CSS selectors
applies
to the whole @ (meaning that it wasn't @meda screen, @media
print)
From css3 (http://www.w3.org/TR/css3-reader/):
@import my-print-style.css print;
here
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
as 5.0.*, etc. Regarding the use of floating points to represent versions... I was wondering whether we should avoid this since it would prevents us from supporting major.minor.reallyminor version strings. I don't know that we will ever need to go further than major.minor, though the Gecko versions use the third digit, so perhaps we should pick a solution that doesn't preclude us from supporting this? (BTW, sorry all about my little digression earlier on the thread...) Andy -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
I have to admit it's +1 from me to option 5) :) On Sat, Apr 19, 2008 at 12:21 AM, Andrew Robinson [EMAIL PROTECTED] wrote: +1 On Fri, Apr 18, 2008 at 4:19 PM, Andy Schwartz [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan [EMAIL PROTECTED] wrote: OK, how about option 5) I like option 5. Andy -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
On Thu, Apr 17, 2008 at 8:04 AM, Blake Sullivan [EMAIL PROTECTED]
wrote:
Cristi Toth said the following On 4/16/2008 5:34 PM PT:
Hi Blake,
I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.
But it's a good idea to follow a (possible) future standard.
I agree. While still only a candidate recommendation, the goal of the
Trinidad CSS syntax has always been to be forward looking (thus the use of
CSS3-style namespaces). As the media query syntax is by far the most likely
syntax to be specified, we should go with that syntax over one of our own
design. That both Opera and WebKit have bothered to implement the
specification is also a good sign.
I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)
I didn't see one, but I don't think that you really want a list here
anyway. Don't you really want all versions of IE = 5 and 8?
Let's say that any list could be defined like several intervals, but it
would have been more flexible.
I think my proposal for abusing a definition of max-version is weak (the
specification discussion is pretty clear the min- prefix means = and the
max- prefix means =). So I think that a more explicit feature suffix
would be better. For example:
@agent ie and (min-version:5) and (max-version-less-than:8), gecko, safari
max...less-than sounds a little bit redundant
maybe something like (version-lt:8) , in general 'version-' followed by an
EL comparison operator (eq, ne, lt, le, gt, ge)?
what do you say ?
@Andrew
Currently (and in the XSS format) version is compared with
TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed
string.
I don't know what it means, but I assume it's very browser dependent.
Determining a floating point browser version isn't a technical problem and
should be supported. The Gecko engine is an example of an engine that adds
CSS features in point releases 1.8 - 1.9 for example.
At least what I could do for now is to support Double instead of Integer
but what if some agents have versions like dates or text?
I'm not aware of how most of the browsers define their version
and I wouldn't want to mess up TrinidadAgent right now, seeing that nobody
asked for this feature until now.
My goal was only to add the feature that was supported in the XSS.
Does anyone know more details about agent's versions in general?
-- Blake Sullivan
But do you see a use-case when you would need different css for minor
versions?
Like a difference between IE 5.0 and 5.5 ?
It would be nice to get to a final conclusion,
so I can update this solution before the next release.
regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan [EMAIL PROTECTED]
wrote:
Cristi,
I think that we should follow a subset of the syntax of CSS Media
Queries http://www.w3.org/TR/css3-mediaqueries/ for consistency as
this is a CSS file. If there are other standard syntaxes for CSS, we can
use one of those instead.
Your rule below could be expressed in such a syntax as:
@agent ie and (min-version:5) and (max-version:7), gecko, safari
Assuming that we chose a convenient definition for ma-version (that it
includes all version up to but not including an increment of the smallest
specified digit. so that max-version:7 really means version 8, while
max-version 7.5 really means version 7.6)
-- Blake Sullivan
Cristi Toth said the following On 4/16/2008 3:24 PM PT:
Hi guys,
I finally added browser version support in skinning, but using a
different format than first suggested.
As we needed to support multiple browsers, each with multiple versions,
I have chosen to use this format:
@ agent ie 5 6 7, gecko,safari {}
So each agent definition separated by comma and the versions a space
separated list following the browser type.
Also in the code I replaced :
int[] browsers
int[] versions
with :
Map Integer, SetInteger browsers
this represents browser types mapped to their versions set.
If you have any objections on this, please reopen the issue and add some
comments
Regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
Hi guys, You're right, I should have discussed the format before committing it. I started fixing the issue using the format that was specified there... (there weren't to many comments on that issue btw...) During I was fixing it, I noticed that XSS suppported multiple versions, so I adapted what was suggested on the issue to support that too. Anyway, lets get this subject out in a new thread and stick here to discussing the format. Guys, those of you that suggested some general guidelines, they all sound good, but please try to think of some concrete format that comply with those guidelines. If we decide a final format and implement it until its get released, then no big harm done. So please be constructive ;) Thanks for any feedback! cheers, -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
On Thu, Apr 17, 2008 at 9:58 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Andrew Robinson said the following On 4/17/2008 12:35 PM PT: So do I read this correctly that for #3, 8 means 8.x so a max-version of 8 means any browser agent with a major version of 8 or less an not even look at the minor version? I'm proposing that the version feature reflect the best floating point version number we can calculate for the browser, which will usually be a combination of the major and minor version, so the version for IE 5.5 will be the floating point number 5.5 Does anybody KNOW how the browsers express their version exactly? Because TrinidadAgent currently only has majorVersion and agentVersion (the latter being an unparsed string). I will have to parse that agentVersion to also get out the minor version. Does anybody know why this wasn't done initially? (any reason like too different between the browsers?) 8 is promoted to 8.0 and since max- means less-than-or-equal-to:max-version:8 means version = 8.0 == true -- Blake Sullivan -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
On Thu, Apr 17, 2008 at 11:15 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Cristi Toth said the following On 4/17/2008 2:00 PM PT Does anybody KNOW how the browsers express their version exactly? Because TrinidadAgent currently only has majorVersion and agentVersion (the latter being an unparsed string). I will have to parse that agentVersion to also get out the minor version. Does anybody know why this wasn't done initially? (any reason like too different between the browsers?) I can't remember why I wrote the code the way I did 12 years ago, but assuming that I was lazy and didn't think that it probably mattered that much at the time is probably a good bet. :) I assume you can't donate prematurely those regex, right? -- Blake Sullivan 8 is promoted to 8.0 and since max- means less-than-or-equal-to:max-version:8 means version = 8.0 == true -- Blake Sullivan -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Resolved: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cristi Toth resolved TRINIDAD-799.
--
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
Assignee: Cristi Toth
I fixed this issue but using another format.
As we needed to support multiple browsers, each with multiple versions, I have
chosen to use this format:
@ agent ie 5 6 7, gecko,safari {}
so each agent definition separated by comma and the versions a space separated
list following the browser type.
if you have any objections on this, please reopen the issue.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Cristi Toth
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1043) Convert legacy XSS files to CSS
[ https://issues.apache.org/jira/browse/TRINIDAD-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589751#action_12589751 ] Cristi Toth commented on TRINIDAD-1043: --- Trinidad-799 (the issue TRINIDAD-1042 duplicated) was resolved Convert legacy XSS files to CSS --- Key: TRINIDAD-1043 URL: https://issues.apache.org/jira/browse/TRINIDAD-1043 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.6-core, 1.2.7-core Reporter: Andy Schwartz Under the covers Trinidad still uses the legacy XSS style definition mechanism (eg. see base-desktop.xss). Logging this issue to request that we port all remaining XSS files over to CSS skins files. Note that before we do that, there are a few features that need to be added to CSS. See: TRINIDAD-1041 Support locale-specific styles TRINIDAD-1042 Support (browser) version-specific styles We may also need to add support for the XSS includeProperty mechanism. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] added browser version support in skinning TRINIDAD-799
Hi guys,
I finally added browser version support in skinning, but using a different
format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I
have chosen to use this format:
@ agent ie 5 6 7, gecko,safari {}
So each agent definition separated by comma and the versions a space
separated list following the browser type.
Also in the code I replaced :
int[] browsers
int[] versions
with :
Map Integer, SetInteger browsers
this represents browser types mapped to their versions set.
If you have any objections on this, please reopen the issue and add some
comments
Regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] added browser version support in skinning TRINIDAD-799
Hi Blake,
I wanted to be backwards compatible with what the XSS offered.
So I assumed that we's want just a list (not necessarily an interval)
And I picked the easiest to parse format.
But it's a good idea to follow a (possible) future standard.
I had a quick look over it's syntax, but not enough.
Isn't there a way to have a list of numbers?
smth like : @agent ie (version: 5 7)
@Andrew
Currently (and in the XSS format) version is compared with
TrinidadAgent.getAgentMajorVersion()
it also has a getAgentVersion() method that returns the full unparsed
string.
I don't know what it means, but I assume it's very browser dependent.
But do you see a use-case when you would need different css for minor
versions?
Like a difference between IE 5.0 and 5.5 ?
It would be nice to get to a final conclusion,
so I can update this solution before the next release.
regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
On Thu, Apr 17, 2008 at 1:14 AM, Blake Sullivan [EMAIL PROTECTED]
wrote:
Cristi,
I think that we should follow a subset of the syntax of CSS Media
Querieshttp://www.w3.org/TR/css3-mediaqueries/for consistency as this is a
CSS file. If there are other standard syntaxes
for CSS, we can use one of those instead.
Your rule below could be expressed in such a syntax as:
@agent ie and (min-version:5) and (max-version:7), gecko, safari
Assuming that we chose a convenient definition for ma-version (that it
includes all version up to but not including an increment of the smallest
specified digit. so that max-version:7 really means version 8, while
max-version 7.5 really means version 7.6)
-- Blake Sullivan
Cristi Toth said the following On 4/16/2008 3:24 PM PT:
Hi guys,
I finally added browser version support in skinning, but using a different
format than first suggested.
As we needed to support multiple browsers, each with multiple versions, I
have chosen to use this format:
@ agent ie 5 6 7, gecko,safari {}
So each agent definition separated by comma and the versions a space
separated list following the browser type.
Also in the code I replaced :
int[] browsers
int[] versions
with :
Map Integer, SetInteger browsers
this represents browser types mapped to their versions set.
If you have any objections on this, please reopen the issue and add some
comments
Regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [jira] Resolved: (TRINIDAD-799) Add agent version support in skinning
@Andrew follow this thread:
[Trinidad] added browser version support in skinning TRINIDAD-799
On Thu, Apr 17, 2008 at 12:36 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
what about minor versions (IE 5.5)?
On Wed, Apr 16, 2008 at 4:13 PM, Cristi Toth (JIRA)
dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Cristi Toth resolved TRINIDAD-799.
--
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
Assignee: Cristi Toth
I fixed this issue but using another format.
As we needed to support multiple browsers, each with multiple versions,
I have chosen to use this format:
@ agent ie 5 6 7, gecko,safari {}
so each agent definition separated by comma and the versions a space
separated list following the browser type.
if you have any objections on this, please reopen the issue.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL:
https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Cristi Toth
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning
developer to differentiate between different browser versions. For example,
it is possible to tell the difference between IE and firefox, but not
between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow
developers to use a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods * We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!!* If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] private / protected final methods in renderers
What I meant with on specific use cases was case by case So I agree with this approach. But I don't want to get the same negative feedback with the same arguments on cases where it's really useful to have protected methods. Oh! One more thing: we also agree that renderers are not 100% guaranteed to be backwards compatible on each new release. Right? cheers, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 10:42 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!! If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
Hi, Let me add some things to what I already stated here. There are 2 important reason for overriding renderers, that nobody mentioned here. 1) Not all users needs are general enough to be comitted into Trinidad. I myself encountered some very custom features required by some customers, that I simply said, there's no way I'll commit this in Trinidad. 2) Custom components When developers build some custom components, they usually extend the existing ones and most of the cases extend also the renderers. That's code reusability and flexibility, right? So for these types of cases, you have to support in some way the renderer overriding. Another reason for not complaining to much about renderer backward compatibility is that companies tend not to upgrade dependencies any more, when they have a relatively stable product. Not to mention that if the user duplicates the whole renderer, he'll have even more problems when upgrading. Thanks Andrew for trying to organize this thread. I totally support : 3) introduce some configurable way to override default behavior for rendering certain areas of components. The best way is having some smaller renderers that are delegated to render parts of components. As Andrew suggested, faces-config seems the perfect way to support overriding those 'sub-renderers'. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu For these 2 points, I really want to make myself clear. I have NOT even thought of promoting ALL private members to protected. Of course only if really helpful for overriding. And as Gabrielle stated, we never made promises of renderer backwards compatibility. Regards, -- Cristi Toth - Codebeat www.codebeat.ro On Fri, Apr 11, 2008 at 11:02 PM, Gabrielle Crawford [EMAIL PROTECTED] wrote: Generally I really do agree with Simon that a simple, serious redesign of every component would probably do better than hooks. Also, I really think once you put restrictions on your renderers you run into issues, like you have a bug or a new feature which makes you need to reorganize in an unexpected way. I'm fine with making it easier to subclass renderers for those that want to take the risk, but I'm -1 on any scheme that restricts our ability to make changes when the need arises. Other comments inline: Andrew Robinson wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible -1, the renderers have to be able to change without worrying about backwards compatibility. 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api Maybe I've misunderstood, but this sounds like it's basically the same as 1 but for pieces of a renderer, -1. 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu I think removing final modifiers AFTER discussion is fine, and I think if people want to risk extending renderers then fine, but we make no promises they will not break at the next release. Same for 5 below. Thanks, Gab 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
(RendererUtils.java:492)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:513)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:492)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556)
... 41 more
Caused by: javax.faces.FacesException: Exception while calling
encodeEnd on
component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174][Class: org.apache.myfaces.custom.subform.SubForm,Id:
questionForm][Class: javax.faces.component.html.HtmlPanelGrid,Id:
j_id181][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id191]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:515)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:221)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:102)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556)
... 47 more
Caused by: javax.faces.FacesException: Exception while calling
encodeBegin
on component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174][Class: org.apache.myfaces.custom.subform.SubForm,Id:
questionForm][Class: javax.faces.component.html.HtmlPanelGrid,Id:
j_id181][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id191][Class: javax.faces.component.html.HtmlCommandButton,Id:
questionSave]}
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:531)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:506)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:492)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556)
... 51 more
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.AutoSubmitUtils.getFullPageSubmitScript(AutoSubmitUtils.java:105)
at
org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlCommandButtonRenderer.encodeBegin(HtmlCommandButtonRenderer.java:99)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:528)
... 55 more
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] private / protected final methods in renderers
I like very much Andrew's idea of having more smaller renderers
and being able to override them the standard way (via faces-config.xml)
Also maybe some of you understood me wrong.
I didn't mean that all/most of the renderer methods should be protected.
But there are cases where it's needed.
Lets take for example some not so trivial scripts that are generated
in a private method,
which is called from a larger protected method.
If somebody wants to override the protected method,
it has to duplicate the script rendering method because he can't call it.
IMO it's not so hard to think of a stable method signature for that
kind of cases.
On 4/11/08, Martin Marinschek [EMAIL PROTECTED] wrote:
Sounds like a reasonable suggestion - I would love to be able to
replace/extend small chunks of code, not having to rewrite/copy the
renderer-code fully, so this suggestion might go into this direction.
regards,
Martin
On 4/11/08, Andrew Robinson [EMAIL PROTECTED] wrote:
Okay, I have yet another approach that I thought of while walking my
dogs that is much more JSF-ish and goes along with Christi's email on
sub-renderers.
Instead creating a whole bloody wrapper API framework that would make
the API hard to change, what about breaking the renderers down even
more into subclasses.
Take the tr:panelPopup for example again. It has:
Outer container
Trigger
Popup
Title bar
Close button
Body
So lets say this is how the renderer could be built:
First, create a bunch of renderer types:
org.apache.myfaces.trinidad.Popup
org.apache.myfaces.trinidad.Popup.Trigger
org.apache.myfaces.trinidad.Popup.PopupShell
org.apache.myfaces.trinidad.Popup.TitleBar
org.apache.myfaces.trinidad.Popup.ButtonArea
org.apache.myfaces.trinidad.Popup.Body
Then register a default renderer for each of these types.
Then the PanelPopupRenderer would in encodeAll:
render outer DIV (ppr stuff)
call a render utils method to get the renderer for the trigger and encode
it
call a render utils method to get the renderer for the popup shell and
encode it
in the popup shell renderer:
encode the outer HTML
call a render utils method to get the renderer for the title bar and
encode
it
call a render utils method to get the renderer for the popup body and
encode
it
in the title bar renderer:
encode the outer HTML
encode the title
call a render utils method to get the renderer for the button area and
encode it
in the body renderer:
encode the outer HTML
encode the children components
This way there are many renderers to one component. The renderers
would be registered in the faces-config.xml just like any ordinary
renderers. Since the FacesBean allows renderers to encode any
component that has certain property keys, this is ideal.
Take for example the close button on the popup, we could have a faces
bean alias wrapper. What I mean by this is something like this:
public class PopupTitleBarRenderer extends XhtmlRenderer {
protected void encodeAll(FacesContext context, RenderingContext rc,
UIComponent component, FacesBean bean) throws IOException {
FacesBean wrapped = new AliasedFacesBean(bean);
wrapped.map(text, title);
...
This way a command button renderer could be used to render the close
button using the title from the dialog as the text of the button.
Using this way, the only exposed API are the sub-renderer types that
can be defined in the faces config. New types can be added and old
ones removed without breaking Java interfaces or abstract class APIs
(although it would have to be controlled to not break custom code too
badly).
-Andrew
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] delegated sub-renderers
Andrew I really like you idea from the other thread (the trick one :) ). Having new renderer types in the API and being able to override them via faces-config sounds much more standard and clean. Probably we should wait and see where the other thread leads to and then start a vote on this regards, On 4/11/08, Scott O'Bryan [EMAIL PROTECTED] wrote: Sorry, this went to the wrong thread. Please disregard. Scott Scott O'Bryan wrote: So if this is the case (ie- people who extend impl expect things to break and know what they are doing), why is it so hard for these people to submit a patch to add a protected or remove a final? Again, everything will remain binary compatible. Scott Cristi Toth wrote: Ok, so if you are pro, which solution do you prefer? And if the configurable one (1st) than what kind of implementation do you think of? On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ++1 On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you want to here my opinion: we need Trinidad to be as customizable as possible. People who do this customization will know what they are doing - and will know how to handle an upgrade to a new version. It is enough to say: this is part of the impl package - it might change from version to version, your own fault, if you extend it and it breaks! IMHO, Adam is wrong in this regard. regards, Martin On 4/10/08, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: But what does the open-source mean then... ? All the renderers are in the impl packages, but that's the beauty of open-source... you can customize something you need. That's an advantage that we should not oversee. On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am not sure if you will get much support as Trinidad has all the renderers in the impl package, and therefore should not be considered part of its api and also should not be extended. Fighting this and asking for more APIs in the past was fruitless for me, but then again that was when Adam Winer was the constant one to veto all improvements. On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, As you probably know, there are a lot of composed renderers in Trinidad which delegate to other subrenderers to render parts of the component. i.e. Table renderer delegates to: - NavBar(subclass of SelectRangeChoiceBarRenderer), - AllDetails (subclass of ShowDetailRenderer) - DetailColumnRenderer input fields renderers (subclasses of InputLabelAndMessageRenderer) delegate to: - one renderer that renders the input field (subclass of FormInputRenderer) - Label (subclass of OutputLabelRenderer) - Message (subclass of MessageRenderer) and many more... As this may look like good practice, it makes life hell for the developers that want to customize/override these renderers. I have 2 possible solutions: 1. make some xml config file that maps a sub-renderer type to a renderer class I know this might look like the old uix practice, but it's for a differernt reason. With a small xsd and some docs, this will be much more transparent. 2. at least have protected getters that return a renderer instance either for using the default defined sub-renderer in an overriden method or just for overriding that sub-renderer itself I personally like the 1st solution more, because it's easier to override sub-renderers defined in a super class of more renderers (LabelAndMessageRenderer) Opinions, suggestions, other solutions? regards -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- http://www.irian.at Your
Re: [Trinidad] private / protected final methods in renderers
Well, between having developers not being able to override some simple behaviour and keeping backwards compatibility on subclassers, I'll choose the 2nd one. This is the reason that some components from tomahawk, that are less feature-enabled that thos in Trinidad, are considered more flexible and easier to customize than the ones in Trinidad. Quite some experienced MyFaces developers told me to forget overriding table and input renderers in Trinidad (some of the most frequently used renderers). So between not having a feature at all and being careful not to break backwards compatibility on some methods, the second one doesn't seem that bad, but the first one does. regards, On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan [EMAIL PROTECTED] wrote: The reason is that each time we make one of these methods protected, we have to guarantee that we will maintain the semantics of that hook until the end-of-time or risk breaking users of that hook. By slowly opening up the api we get the developers to tell us what they need and can weigh the benefit against the support cost. If the hooks don't require that super be called, in many ways, it is safer to completely override the function. This is the general issue of the competing desires to make it easy to tweak a renderer by subclassing without needing to completely replace it vs. a desire to be able to change the Renderer implementation without breaking subclassers. I actually think that we went too far in providing lots of subclasser knobs in Trinidad, but that's just my opinion. -- Blake Sullivan Cristi Toth said the following On 4/9/2008 5:23 PM PT: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
One more thing, Trinidad now being open-source means that it should be really open for those advanced developers that dive into the code. On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth [EMAIL PROTECTED] wrote: Well, between having developers not being able to override some simple behaviour and keeping backwards compatibility on subclassers, I'll choose the 2nd one. This is the reason that some components from tomahawk, that are less feature-enabled that thos in Trinidad, are considered more flexible and easier to customize than the ones in Trinidad. Quite some experienced MyFaces developers told me to forget overriding table and input renderers in Trinidad (some of the most frequently used renderers). So between not having a feature at all and being careful not to break backwards compatibility on some methods, the second one doesn't seem that bad, but the first one does. regards, On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan [EMAIL PROTECTED] wrote: The reason is that each time we make one of these methods protected, we have to guarantee that we will maintain the semantics of that hook until the end-of-time or risk breaking users of that hook. By slowly opening up the api we get the developers to tell us what they need and can weigh the benefit against the support cost. If the hooks don't require that super be called, in many ways, it is safer to completely override the function. This is the general issue of the competing desires to make it easy to tweak a renderer by subclassing without needing to completely replace it vs. a desire to be able to change the Renderer implementation without breaking subclassers. I actually think that we went too far in providing lots of subclasser knobs in Trinidad, but that's just my opinion. -- Blake Sullivan Cristi Toth said the following On 4/9/2008 5:23 PM PT: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] delegated sub-renderers
But what does the open-source mean then... ? All the renderers are in the impl packages, but that's the beauty of open-source... you can customize something you need. That's an advantage that we should not oversee. On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson [EMAIL PROTECTED] wrote: I am not sure if you will get much support as Trinidad has all the renderers in the impl package, and therefore should not be considered part of its api and also should not be extended. Fighting this and asking for more APIs in the past was fruitless for me, but then again that was when Adam Winer was the constant one to veto all improvements. On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi, As you probably know, there are a lot of composed renderers in Trinidad which delegate to other subrenderers to render parts of the component. i.e. Table renderer delegates to: - NavBar(subclass of SelectRangeChoiceBarRenderer), - AllDetails (subclass of ShowDetailRenderer) - DetailColumnRenderer input fields renderers (subclasses of InputLabelAndMessageRenderer) delegate to: - one renderer that renders the input field (subclass of FormInputRenderer) - Label (subclass of OutputLabelRenderer) - Message (subclass of MessageRenderer) and many more... As this may look like good practice, it makes life hell for the developers that want to customize/override these renderers. I have 2 possible solutions: 1. make some xml config file that maps a sub-renderer type to a renderer class I know this might look like the old uix practice, but it's for a differernt reason. With a small xsd and some docs, this will be much more transparent. 2. at least have protected getters that return a renderer instance either for using the default defined sub-renderer in an overriden method or just for overriding that sub-renderer itself I personally like the 1st solution more, because it's easier to override sub-renderers defined in a super class of more renderers (LabelAndMessageRenderer) Opinions, suggestions, other solutions? regards -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:515)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:221)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:102)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556)
... 47 more
Caused by: javax.faces.FacesException: Exception while calling
encodeBegin
on component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174][Class: org.apache.myfaces.custom.subform.SubForm,Id:
questionForm][Class: javax.faces.component.html.HtmlPanelGrid,Id:
j_id181][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id191][Class: javax.faces.component.html.HtmlCommandButton,Id:
questionSave]}
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:531)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:506)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:492)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556)
... 51 more
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.AutoSubmitUtils.getFullPageSubmitScript(AutoSubmitUtils.java:105)
at
org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlCommandButtonRenderer.encodeBegin(HtmlCommandButtonRenderer.java:99)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:528)
... 55 more
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
Well I think we don't see the problem in the same way. What does good design mean in this case ...!? Making some methods protected and remove the final for others doesn't hurt Trinidad itself at all. So you can't say this is bad design. If the bad design refers to what we offer the clients, than this is definitely wrong. Because a quite a lot of clients that me or some of my collaborators have interacted with, have complained a lot about Trinidad code that's so CLOSED !!! Many said that instead of trying a small feature to the trinidad table, you better take the Tomahawk one, and add all the feature you need on it. It's easier and cleaner. The faces-config allows you to override any renderer for any component, right !? So renderers are meant to be overriden. (by the JSF spec) This is the beauty of JSF, because it's so flexible and customizable. How do you expect to override Trinidad renderers? Copying all the code and make some small changes? Imagine that overriding some behaviour of some larger renderers, you have to override the whole renderer hierarchy (i.w. LabelAndMessageRenderer). Between duplicating the whole renderer code and just having some protected renderer methods, which sounds better in design? If we talk about backwards compatibilty, then imagine a whole duplicated renderer which isn't aware of any other updated renderers... And if a custom renderer developer gets a compile error after an update, I assume it won't take him to much time to fix it... If a renderer is not in the API, this means that it shouldn't be overriden !? Let's think a bit out of the box and try to figure what's best for the client. Because that's what matters most... regards, On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: The overuse of final is largely irrelevant in impl packages. The reason is that removing a final allows the class to remain binary compatible and only items inside of the impl package should be extending the class. In some cases, final helps ensure an implied contract. In other words, if something is final, you know it's implemented nowhere else. In API's I agree with Andy, final should be used only to enforce a contract that should not (can not) change. Most commonly this is used on immutable classes/api but it has some other uses. Scott Andy Schwartz wrote: Hi Andrew - On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I wasn't suggesting blind removal. Okay. The use of the word most gave me that impression. :-) IMO final should rarely ever be used, for open source it almost never does anyone any good. Final should be used for its intended purpose. Sure, in some cases final may be abused, but then those cases should be corrected. That doesn't mean that final should rarely be used - it should be used when appropriate. Again, I don't see how open vs. closed source comes into play here. Good API design is good API design, whether open or closed source. I would suggest a renderer-by-renderer approach though, not method-by-method as that would take too long to file that many bugs. I am not sure I understand the difference between these approaches. At some point somebody will need to evaluate specific methods to determine whether changes are required. Personally I prefer the approach that Blake alluded to, which is to open things up as the need arises. (I may have missed it, but I don't remember seeing the particular offending cases which triggered this discussion.) Right now Trinidad and facelets are by far the most inflexible open source code I have worked with. Both over-use final and both assume that out-of-the box behavior is enough fore everyone's needs. For Trinidad renderers, many only expose encodeAll as protected then do most of the work in private methods. As a result a person needing to customize a renderer has to use copy paste (generate an entirely new renderer using the source of the core one) which really sucks for maintenance. I don't understand this at all. Why would anyone do that, vs. log an issue, submit a patch, fix the problem, revel in the magic of open source? Is the issue here really that the renderers as a whole are considered off-limits to subclassing, due to the fact that they are located in trinidadinternal (not trinidadapi)? Andy -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] delegated sub-renderers
Ok, so if you are pro, which solution do you prefer? And if the configurable one (1st) than what kind of implementation do you think of? On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson [EMAIL PROTECTED] wrote: ++1 On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek [EMAIL PROTECTED] wrote: If you want to here my opinion: we need Trinidad to be as customizable as possible. People who do this customization will know what they are doing - and will know how to handle an upgrade to a new version. It is enough to say: this is part of the impl package - it might change from version to version, your own fault, if you extend it and it breaks! IMHO, Adam is wrong in this regard. regards, Martin On 4/10/08, Cristi Toth [EMAIL PROTECTED] wrote: But what does the open-source mean then... ? All the renderers are in the impl packages, but that's the beauty of open-source... you can customize something you need. That's an advantage that we should not oversee. On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson [EMAIL PROTECTED] wrote: I am not sure if you will get much support as Trinidad has all the renderers in the impl package, and therefore should not be considered part of its api and also should not be extended. Fighting this and asking for more APIs in the past was fruitless for me, but then again that was when Adam Winer was the constant one to veto all improvements. On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi, As you probably know, there are a lot of composed renderers in Trinidad which delegate to other subrenderers to render parts of the component. i.e. Table renderer delegates to: - NavBar(subclass of SelectRangeChoiceBarRenderer), - AllDetails (subclass of ShowDetailRenderer) - DetailColumnRenderer input fields renderers (subclasses of InputLabelAndMessageRenderer) delegate to: - one renderer that renders the input field (subclass of FormInputRenderer) - Label (subclass of OutputLabelRenderer) - Message (subclass of MessageRenderer) and many more... As this may look like good practice, it makes life hell for the developers that want to customize/override these renderers. I have 2 possible solutions: 1. make some xml config file that maps a sub-renderer type to a renderer class I know this might look like the old uix practice, but it's for a differernt reason. With a small xsd and some docs, this will be much more transparent. 2. at least have protected getters that return a renderer instance either for using the default defined sub-renderer in an overriden method or just for overriding that sub-renderer itself I personally like the 1st solution more, because it's easier to override sub-renderers defined in a super class of more renderers (LabelAndMessageRenderer) Opinions, suggestions, other solutions? regards -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] why does Trinidad override javax.faces.* renderers?
* at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.AutoSubmitUtils.getFullPageSubmitScript( *AutoSubmitUtils.java:105*) at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlCommandButtonRenderer.encodeBegin( *HtmlCommandButtonRenderer.java:99*) at javax.faces.component.UIComponentBase.encodeBegin(* UIComponentBase.java:528*) ... 55 more -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] delegated sub-renderers
Hi, As you probably know, there are a lot of composed renderers in Trinidad which delegate to other subrenderers to render parts of the component. i.e. Table renderer delegates to: - NavBar(subclass of SelectRangeChoiceBarRenderer), - AllDetails (subclass of ShowDetailRenderer) - DetailColumnRenderer input fields renderers (subclasses of InputLabelAndMessageRenderer) delegate to: - one renderer that renders the input field (subclass of FormInputRenderer) - Label (subclass of OutputLabelRenderer) - Message (subclass of MessageRenderer) and many more... As this may look like good practice, it makes life hell for the developers that want to customize/override these renderers. I have 2 possible solutions: 1. make some xml config file that maps a sub-renderer type to a renderer class I know this might look like the old uix practice, but it's for a differernt reason. With a small xsd and some docs, this will be much more transparent. 2. at least have protected getters that return a renderer instance either for using the default defined sub-renderer in an overriden method or just for overriding that sub-renderer itself I personally like the 1st solution more, because it's easier to override sub-renderers defined in a super class of more renderers (LabelAndMessageRenderer) Opinions, suggestions, other solutions? regards -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] private / protected final methods in renderers
Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Commented: (TRINIDAD-951) Printable output mode produces javascript errors
[
https://issues.apache.org/jira/browse/TRINIDAD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586596#action_12586596
]
Cristi Toth commented on TRINIDAD-951:
--
btw, thanks to Harald Kuhn for most of the bits of code
Printable output mode produces javascript errors
Key: TRINIDAD-951
URL: https://issues.apache.org/jira/browse/TRINIDAD-951
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.2-core
Environment: Jdk 1.6, Jetty 6.1.5, Facelets 1.1.13, MyFaces JSF
1.2.2, Trinidad 1.2.2
Reporter: Joe Rossi
Assignee: Cristi Toth
Priority: Minor
Fix For: 1.0.8-core, 1.2.8-core
A page rendered with trinidad-config.xml output-mode set to printable
contains javascript errors. The example below (widgetList.xhtml) contains a
couple of command buttons and a table. When the command button 'Printable
Page' is clicked it sets the requestScope.outputMode to 'printable' and this
is used to drive the output-mode setting in trinidad-config.xml. Looking at
the generated html, it looks like there is no reference to the usual
javascript file required by Trinidad (DebugCommon1_2_2.js or Common1_2_2.js).
trinidad-config.xml:
===
?xml version=1.0?
trinidad-config xmlns=http://myfaces.apache.org/trinidad/config;
!--
Enable this setting to cause Trinidad to generate debug output.
debug-outputtrue/debug-output
--
skin-familytn/skin-family
output-mode#{requestScope.outputMode}/output-mode
/trinidad-config
Test file: widgetList.xhtml:
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
tr:document id=testForm title=test form
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:tr=http://myfaces.apache.org/trinidad;
tr:panelBorderLayout
tr:form id=widgetListForm
tr:panelGroupLayout layout=vertical
tr:commandButton text=Create New Widget
action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=createWidgetCommand
tr:setActionListener from=#{widgetListBean.newWidgetBean}
to=#{pageFlowScope.widgetBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.widgetBean.operation} /
/tr:commandButton
tr:commandButton text=Refresh Page id=refreshCommand
/tr:commandButton
tr:commandButton text=Printable Page id=printablePageCommand
tr:setActionListener from=#{'printable'}
to=#{requestScope.outputMode} /
/tr:commandButton
tr:table id=widgetTable var=widgetBean
value=#{widgetListBean.widgetList} rowBandingInterval=1
partialTriggers=refreshCommand createWidgetCommand
widgetTable:editWidgetCommand widgetTable:deleteWidgetCommand
tr:column
f:facet name=header
tr:outputText value=Widget Name /
/f:facet
tr:outputText value=#{widgetBean.name} /
/tr:column
tr:column
f:facet name=header
tr:outputText value=Actions /
/f:facet
tr:panelGroupLayout layout=horizontal
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=editWidgetCommand
shortDesc=Edit the widget.
tr:image source=/skins/tn/images/ico_edit.gif /
tr:setActionListener from=#{'edit'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=deleteWidgetCommand
shortDesc=Delete the widget.
returnListener=#{widgetListBean.processReturn}
tr:image source=/skins/tn/images/ico_delete.gif /
tr:setActionListener from=#{'delete'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
/tr:panelGroupLayout
/tr:column
/tr:table
/tr:panelGroupLayout
/tr:form
/tr:panelBorderLayout
/tr:document
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-951) Printable output mode produces javascript errors
[
https://issues.apache.org/jira/browse/TRINIDAD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cristi Toth resolved TRINIDAD-951.
--
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
Assignee: Cristi Toth
I fixed some renderers using statement similar to this:
if (supportsScripting(rc))
{
...
old code rendering scripts
..
}
this is because in output mode printable scripting is disabled
so no need for rendering scripts or on event handlers
they usually generated js erros because the js dependencies were not found
Printable output mode produces javascript errors
Key: TRINIDAD-951
URL: https://issues.apache.org/jira/browse/TRINIDAD-951
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.2-core
Environment: Jdk 1.6, Jetty 6.1.5, Facelets 1.1.13, MyFaces JSF
1.2.2, Trinidad 1.2.2
Reporter: Joe Rossi
Assignee: Cristi Toth
Priority: Minor
Fix For: 1.0.8-core, 1.2.8-core
A page rendered with trinidad-config.xml output-mode set to printable
contains javascript errors. The example below (widgetList.xhtml) contains a
couple of command buttons and a table. When the command button 'Printable
Page' is clicked it sets the requestScope.outputMode to 'printable' and this
is used to drive the output-mode setting in trinidad-config.xml. Looking at
the generated html, it looks like there is no reference to the usual
javascript file required by Trinidad (DebugCommon1_2_2.js or Common1_2_2.js).
trinidad-config.xml:
===
?xml version=1.0?
trinidad-config xmlns=http://myfaces.apache.org/trinidad/config;
!--
Enable this setting to cause Trinidad to generate debug output.
debug-outputtrue/debug-output
--
skin-familytn/skin-family
output-mode#{requestScope.outputMode}/output-mode
/trinidad-config
Test file: widgetList.xhtml:
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
tr:document id=testForm title=test form
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:tr=http://myfaces.apache.org/trinidad;
tr:panelBorderLayout
tr:form id=widgetListForm
tr:panelGroupLayout layout=vertical
tr:commandButton text=Create New Widget
action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=createWidgetCommand
tr:setActionListener from=#{widgetListBean.newWidgetBean}
to=#{pageFlowScope.widgetBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.widgetBean.operation} /
/tr:commandButton
tr:commandButton text=Refresh Page id=refreshCommand
/tr:commandButton
tr:commandButton text=Printable Page id=printablePageCommand
tr:setActionListener from=#{'printable'}
to=#{requestScope.outputMode} /
/tr:commandButton
tr:table id=widgetTable var=widgetBean
value=#{widgetListBean.widgetList} rowBandingInterval=1
partialTriggers=refreshCommand createWidgetCommand
widgetTable:editWidgetCommand widgetTable:deleteWidgetCommand
tr:column
f:facet name=header
tr:outputText value=Widget Name /
/f:facet
tr:outputText value=#{widgetBean.name} /
/tr:column
tr:column
f:facet name=header
tr:outputText value=Actions /
/f:facet
tr:panelGroupLayout layout=horizontal
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=editWidgetCommand
shortDesc=Edit the widget.
tr:image source=/skins/tn/images/ico_edit.gif /
tr:setActionListener from=#{'edit'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=deleteWidgetCommand
shortDesc=Delete the widget.
returnListener=#{widgetListBean.processReturn}
tr:image source=/skins/tn/images/ico_delete.gif /
tr:setActionListener from=#{'delete'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean
Re: [Trinidad] xss files?
Hi,
The issue TRINIDAD-1042 duplicates TRINIDAD-799 (which is not assigned to
skinning, but to components)
Andrew originally had these ideas:
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to
use a regex on the browser version:
@agent match /MSIE [67]/
I could at least handle this issue, but we have to agree on one format
and one other short question: should we also support version for platforms?
cheers,
On Sun, Apr 6, 2008 at 3:30 PM, Andy Schwartz [EMAIL PROTECTED]
wrote:
BTW, I didn't see any open Trinidad issues relating to this, so I
decided to go ahead and log a few new issues to track some of the work
that needs to be done. See:
TRINIDAD-1041 Support locale-specific styles
TRINIDAD-1042 Support (browser) version-specific styles
TRINIDAD-1043 Convert legacy XSS files to CSS
Andy
--
Cristi Toth
-
Codebeat
www.codebeat.ro
[jira] Commented: (TRINIDAD-1042) Support (browser) version-specific styles
[
https://issues.apache.org/jira/browse/TRINIDAD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586171#action_12586171
]
Cristi Toth commented on TRINIDAD-1042:
---
Hi,
This issue duplicates Trinidad-799 (which is not assigned to skinning, but to
components)
Support (browser) version-specific styles
-
Key: TRINIDAD-1042
URL: https://issues.apache.org/jira/browse/TRINIDAD-1042
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Skinning
Affects Versions: 1.0.6-core, 1.2.7-core
Reporter: Andy Schwartz
Priority: Minor
Under the covers Trinidad still uses the legacy XSS style definition
mechanism (eg. see base-desktop.xss). It would be nice to finally port these
XSS files over to CSS, since the CSS is a far more familiar language.
However, before we can do that, we need to add a few remaining XSS features
which our not present in our CSS skinning implementation.
One feature that we support in XSS but not in CSS is the ability to define
(browser) version-specific styles. In XSS, this is done via the versions
attribute on the styleSheet element. In our CSS skins, we already support
agent-specific styles via @agent rules. Perhaps we can enhance this to
include version information. For example, we currently can do:
@agent ie { ie-specific styles }
It would be nice to be able to do:
@agent ie6 { ie6-specific styles here }
@agent ie7 { ie7-specific styles here }
Logging this issue to request that we add similar support to CSS skinning,
with the goal of being able to convert our XSS files over to CSS.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: NavigationTree skinning/refactored? (TRINIDAD-655)
Hi, AFAIK the navigationTree renderer is an old UIX deprecated renderer and doesn't handle skinning correctly as you noticed. It should be refactored, but neither I nor somebody else found time to do it. But, I think you can use the normal tree component with command components in it. cheers On Wed, Apr 2, 2008 at 11:03 PM, DuBois, Joseph [EMAIL PROTECTED] wrote: Hello again, Since I didn't see a response to my question I did a bit more searching and noticed the following BUG listing (655), and was wondering, since it is listed as still open, if this was something that is being looked at or should I look for an alternative implementation? (which seems to be my problem). I am not fully sure how you guys go about doing fixes and such, so figured I would ask. https://issues.apache.org/jira/browse/TRINIDAD-655 Despite documentation saying that af|navigationTree::disclosed-icon and af|navigationTree::undisclosed-icon may be used to style the navigationTree icons, they are not used by the current renderer which hard-codes the icons to unicode text values in the renderExpandCell method of TreeRenderer Documented at: http://myfaces.apache.org/trinidad/skin-selectors.html Thanks again for any assistance. Joe -Original Message- From: DuBois, Joseph [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 1:32 PM To: MyFaces Development Subject: NavigationTree skinning/refactored? Well met all, First time posting here, and new to Trinidad, so hopefully following proper etiquette. I am looking to re-skin the navigationTree element and in searching the archives on MarkMail I found several threads with references, the most recent was on 2007/10/08 by A.Winer where he talked about it requiring refactoring because it was using the older UIX component and that we'd have a new one in core.xhtml. I contacted Adam, but he said he was no longer working on the project, thus he never was able to do it, so I was wondering if this has been done? Second I found a post back in 2007/01/08 again about a skinning the navigationTree, but no responses to that query? So again, looking for help/advise. I need to change the symbol that is displayed to a graphical image. Joe DuBois Children's Hospital Boston [EMAIL PROTECTED] -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Created: (TRINIDAD-1034) breadCrumbs skinning improvement
breadCrumbs skinning improvement Key: TRINIDAD-1034 URL: https://issues.apache.org/jira/browse/TRINIDAD-1034 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.2.7-core, 1.0.7-core Reporter: Cristi Toth Assignee: Cristi Toth Priority: Minor Add new skin-properties for skinning breadCrumbs in the case of vertical orientation: af|breadCrumbs-tr-separator-on-new-line - put the separator on the new line (before a link) af|breadCrumbs-tr-indent-spaces - number of nbsp's used for indenting a link -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1034) breadCrumbs skinning improvement
[ https://issues.apache.org/jira/browse/TRINIDAD-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth resolved TRINIDAD-1034. --- Resolution: Fixed Fix Version/s: 1.2.8-core 1.0.8-core breadCrumbs skinning improvement Key: TRINIDAD-1034 URL: https://issues.apache.org/jira/browse/TRINIDAD-1034 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Cristi Toth Assignee: Cristi Toth Priority: Minor Fix For: 1.0.8-core, 1.2.8-core Add new skin-properties for skinning breadCrumbs in the case of vertical orientation: af|breadCrumbs-tr-separator-on-new-line - put the separator on the new line (before a link) af|breadCrumbs-tr-indent-spaces - number of nbsp's used for indenting a link -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NavigationTree skinning/refactored?
Hi, The navigationTree renderer was never refactored indeed. I intended to do that, but never had the time. But I think you can use the normal tree with some command components in it. The tree renderer is refactored and has some nice skinning features. regards, On Wed, Mar 26, 2008 at 6:31 PM, DuBois, Joseph [EMAIL PROTECTED] wrote: Well met all, First time posting here, and new to Trinidad, so hopefully following proper etiquette. I am looking to re-skin the navigationTree element and in searching the archives on MarkMail I found several threads with references, the most recent was on 2007/10/08 by A.Winer where he talked about it requiring refactoring because it was using the older UIX component and that we'd have a new one in core.xhtml. I contacted Adam, but he said he was no longer working on the project, thus he never was able to do it, so I was wondering if this has been done? Second I found a post back in 2007/01/08 again about a skinning the navigationTree, but no responses to that query? So again, looking for help/advise. I need to change the symbol that is displayed to a graphical image. Joe DuBois Children's Hospital Boston [EMAIL PROTECTED] -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Created: (TRINIDAD-1019) table pagination (control bar) rendered also at bottom (configurable)
table pagination (control bar) rendered also at bottom (configurable) - Key: TRINIDAD-1019 URL: https://issues.apache.org/jira/browse/TRINIDAD-1019 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.7-core, 1.0.7-core Reporter: Cristi Toth ADF Faces supported rendering trable control bar on top but also on bottom. Reenable that by adding a skinning property af|table::control-bar-position (top|bottom|both) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Redesigned MyFaces website preview
Only on thing, check that the menu headers do not wrap on 2 lines Except this, it looks great. +1 On Wed, Mar 19, 2008 at 8:11 PM, Simon Lessard [EMAIL PROTECTED] wrote: +1, thanks for the hard work, it looks great. On Wed, Mar 19, 2008 at 3:04 PM, Catalin Kormos [EMAIL PROTECTED] wrote: Yeah, i also think we might need to change to XDoc for some of the pages, if we want to them to realy fit as a whole (but we can do this afterwards). Thanks for the quick reviews, i'll leave some more time for others to have a chance to look; i'm thinking, tomorrow evening the new skin will get in. regards, Catalin On Wed, Mar 19, 2008 at 8:53 PM, Michael Kurz [EMAIL PROTECTED] wrote: Catalin Kormos schrieb: I would like to ask for your opinion before starting to commit the new MyFaces Maven skin (based on the designs Adonis provided). +1 from me. Looks really great. regards Michael -- Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [COMMUNITY] MyFaces += Cristian Toth (aka Cristi)
Thanks all for your support! I'll try not to disappoint :) best regards, On Tue, Mar 11, 2008 at 10:47 PM, Martin Marinschek [EMAIL PROTECTED] wrote: Welcome Cristi! Great to have you aboard! regards, Martin On Tue, Mar 11, 2008 at 6:48 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Cristian Cristi Toth as the newest MyFaces committer. Cristi has been providing several patches and has also been very active on the mailing-list! @Cristi: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml (once your karma is set ;-) ) -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Cristi Toth - Codebeat www.codebeat.ro
Re: open link in new window prevention
Hi Mario, Why do you say that some browsers can't open the link in a new window? At least you can use the target attribute of the form and it should work... regards, On Wed, Mar 5, 2008 at 9:39 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Is there any reason that the MyFaces command link is rendered with href=# and onlclick=return xxx() instead of href=javascript: ? It seems, the latter will make the open link in new window feature of some browsers stopping to work. Which is what I'd like to have. What do you think about a context parameter e.g. org.apache.myfaces.OPEN_NEW_WINDOW_PREVENTION=true|false which will change how the commandLink renders the link? The default can be false to be compatible to the current behavior, though, I think defaulting to true wouldn't be that bad. What do you think? Ciao, Mario -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Tomahawk] List of components to be upgraded from sandbox to tomahawk 1.2
it's: optionaltrue/optional On Mon, Mar 3, 2008 at 10:24 PM, Andrew Robinson [EMAIL PROTECTED] wrote: We can reference the component on the tld of tomahawk, but the hypotetical DOJO commons module jar should be referenced too. How we can do this optional? Maven has an optional scope on dependencies. Believe it looks like: dependency groupId / artifactId / version / scopeoptional/scope /dependency -- Cristi Toth - Codebeat www.codebeat.ro
Re: A new look for Trinidad
Hi Andrew, These are very good initiatives and htey would have good impact for promoting Trinidad. I would gladly help in both issues, but as much as my spare time would let me do that. Regards, On Mon, Mar 3, 2008 at 12:32 AM, Andrew Robinson [EMAIL PROTECTED] wrote: I have decided to temporarily quit my side project for various issues, but I still want to contribute to Trinidad, and now can spend some more time on it. When I was doing this project, I was disapointed by Trinidad's skins and its demo. As a result, I have created 979 and 980 Jira issues.: https://issues.apache.org/jira/browse/TRINIDAD-979 https://issues.apache.org/jira/browse/TRINIDAD-980 What I plan to do over the next weeks and months, is to clean up the Trinidad look of Trinidad. I feel that Trinidad will be a lot more popular if it would have a better demo and look better out of the box. Hopefully this will help Trinidad to be a better competitor to JBoss (RichFaces) and other competitors and give the community an interim improvement until, perhaps, the Oracle rich application is donated and makes its way through the incubation process. I may want to start the skin soon and then after that, the demo. I can't see how anyone would object to this, but please let me know if you have any concerns or issues with them. Also, please let me know if you want to help out and can devote some time to either one of these projects and perhaps this can be broken up into different components per person or something. Thanks, Andrew -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] table total row
Hi, I would like to separate the footer and the total row concepts form the Trinidad table. My suggestion sounds like this: - adding a total facet to tr:column - adding a totalRowPosition property to tr:table with the folloing possible values: - top - (just under the column headers - bottom (just above the column footer) - both - none Also from the skinning point of view: - having af|column::footer-text, af|column::footer-number (instead of total...) - using the af|column::total-text, af|column::total-number only for the total row - adding af|table::total-row skin selector to be applied on the tr what do you say about the backward compatiblity of af|column::total-text in the footer? should I render both classes in the footer cell? Please give some feedback (critics) on my suggestion and tell me if you would want this in trinidad! regards, -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] table total row
me again, Also instead of adding a new totalRowPosition property to tr:table we could have totalBottom and totalTop facets to tr:column (instead of total) what's your preference ? On Thu, Feb 28, 2008 at 6:38 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi, I would like to separate the footer and the total row concepts form the Trinidad table. My suggestion sounds like this: - adding a total facet to tr:column - adding a totalRowPosition property to tr:table with the folloing possible values: - top - (just under the column headers - bottom (just above the column footer) - both - none Also from the skinning point of view: - having af|column::footer-text, af|column::footer-number (instead of total...) - using the af|column::total-text, af|column::total-number only for the total row - adding af|table::total-row skin selector to be applied on the tr what do you say about the backward compatiblity of af|column::total-text in the footer? should I render both classes in the footer cell? Please give some feedback (critics) on my suggestion and tell me if you would want this in trinidad! regards, -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Updated: (TRINIDAD-486) Possibility to skin the showdetail-prompt
[ https://issues.apache.org/jira/browse/TRINIDAD-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth updated TRINIDAD-486: - Status: Patch Available (was: Open) Possibility to skin the showdetail-prompt - Key: TRINIDAD-486 URL: https://issues.apache.org/jira/browse/TRINIDAD-486 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Henk Vanhoe Priority: Minor There isn't currently any good way to skin the prompt of the showDetail component. The link uses the OraLink style, and there's no style on the showDetail as a whole, so there's no way to detect just showDetail links. See discussion on adffaces-user mailing list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02791.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] new release(s) ?
Well, I also have one patch on the pipe, so just let us know when you plan to start the release! On Sat, Feb 23, 2008 at 5:16 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Matthias, I agree. Furthermore, I am about to check in significant JavaScript changes to panelPopup to fix some of the location issues that people have been having. I would not mind having the 1.x.7 branches created before that commit so the JS code has some time to bake as a SNAPSHOT for a while. +1 On Sat, Feb 23, 2008 at 5:38 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, due to an important fix for Facelets and Trinidad 1.2.x, a new version of Trinidad 1.2.x is needed. Since there were also fixes for 1.0.x I think we should release both: -107 -127 Do you agree ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] new release(s) ?
meaning this evening? On Sun, Feb 24, 2008 at 1:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: end of this week ? On Sun, Feb 24, 2008 at 1:01 PM, Cristi Toth [EMAIL PROTECTED] wrote: Well, I also have one patch on the pipe, so just let us know when you plan to start the release! On Sat, Feb 23, 2008 at 5:16 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Matthias, I agree. Furthermore, I am about to check in significant JavaScript changes to panelPopup to fix some of the location issues that people have been having. I would not mind having the 1.x.7 branches created before that commit so the JS code has some time to bake as a SNAPSHOT for a while. +1 On Sat, Feb 23, 2008 at 5:38 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, due to an important fix for Facelets and Trinidad 1.2.x, a new version of Trinidad 1.2.x is needed. Since there were also fixes for 1.0.x I think we should release both: -107 -127 Do you agree ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] new release(s) ?
aha, so end of next week (29th) :) ok, sounds good On Sun, Feb 24, 2008 at 1:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: meaning friday :-) On Sun, Feb 24, 2008 at 1:18 PM, Cristi Toth [EMAIL PROTECTED] wrote: meaning this evening? On Sun, Feb 24, 2008 at 1:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: end of this week ? On Sun, Feb 24, 2008 at 1:01 PM, Cristi Toth [EMAIL PROTECTED] wrote: Well, I also have one patch on the pipe, so just let us know when you plan to start the release! On Sat, Feb 23, 2008 at 5:16 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Matthias, I agree. Furthermore, I am about to check in significant JavaScript changes to panelPopup to fix some of the location issues that people have been having. I would not mind having the 1.x.7 branches created before that commit so the JS code has some time to bake as a SNAPSHOT for a while. +1 On Sat, Feb 23, 2008 at 5:38 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, due to an important fix for Facelets and Trinidad 1.2.x, a new version of Trinidad 1.2.x is needed. Since there were also fixes for 1.0.x I think we should release both: -107 -127 Do you agree ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] Release Notes page
Hi, Shouldn't the release page contain at least the list of fixed issues / new features from the release? I think it would be of great help to project managers to decide to do an update or not. I know that it is additional work for the release manager... but a copy/paste of the issue headers would be really useful. On 2/19/08, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, this page: http://myfaces.apache.org/trinidad/release-notes.html is never really maintained. When a new Trinidad release is out, we only update this page: http://myfaces.apache.org/trinidad/download.html (and the myfaces download/news page to reflect the new releae) Two options I see here: -delete the release notes page. -duplicate the content on that page (from the real release notes, which are available on downloads.html) I tend to vote for the 1st option. What is your take on that? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] Release Notes page
Hi, As Curtiss noticed, I just missed the link on the download page to the jira release notes. It's definitely enough. Why not make the link from the menu point to the page on jira? On Feb 19, 2008 5:34 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On Feb 19, 2008 5:22 PM, Curtiss Howard [EMAIL PROTECTED] wrote: My opinion... It's not always obvious that release notes are available on a download page (as a general practice), and the link on the current download page is easy to miss. Furthermore, only the release notes for the latest release are linked. I wouldn't mind seeing the Release Notes page simply be a collection of links to the JIRA release notes for the current release as well as previous releases. that sounds like a much better option instead of copying the content from the JIRA release notes over. -Matthias Curtiss Howard -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Commented: (TRINIDAD-494) Using custom tree expand/collapse icon
[
https://issues.apache.org/jira/browse/TRINIDAD-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567474#action_12567474
]
Cristi Toth commented on TRINIDAD-494:
--
This issue was resolved by Trinidad-769
Using custom tree expand/collapse icon
--
Key: TRINIDAD-494
URL: https://issues.apache.org/jira/browse/TRINIDAD-494
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Reporter: Dzenan Causevic
-Original Message-
From: Jeanne Waldman [mailto:[EMAIL PROTECTED]
Sent: Monday, December 11, 2006 4:40 PM
To: [EMAIL PROTECTED]
Subject: Re: Using custom tree expand/collapse icon
Anything that starts with a .p_ is a private style.
Feel free to submit a JIRA issue against skinning for this feature.
Daniel Hannum wrote:
I'd love to have this. Right now it uses stock characters that don't
always display correctly with all fonts. I get ugly squares on IE for
some fonts.
-Original Message-
From: Causevic, Dzenan [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2006 9:08 AM
To: [EMAIL PROTECTED]
Subject: FW: Using custom tree expand/collapse icon
This is a second call on the same question. Anyone any clue?
Dzenan Causevic
Software Web Developer
NaviSite, Inc.
Syracuse, NY
(315) 453-2912 x5346
-Original Message-
From: Causevic, Dzenan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 3:49 PM
To: [EMAIL PROTECTED]
Subject: Using custom tree expand/collapse icon
Is it possible to use your own custom tree expand/collapse icon that
user clicks on to expand or collapse a subtree?
This is the excerpt from my css file regarding tree components. As
you can see below I am trying to specify background-image that would
supposedly overrun the default one, but I dont get any success, the
default one is still showing thru even if I try to set it to none
(background-image: none;)
/* tree */
/* -- */
.p_OraTreeDisclosedSymbol {
border-right: lightcyan solid 0.5px;
border-bottom: lightcyan solid 0.5px;
background-image: url(/images/showarrow.gif); }
.p_OraTreeNodeAdjust {
font-size: 7pt;
}
.p_OraTreeRow {
background-color: none;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-944) Improvement of table skinning (skinning the sorted column)
Improvement of table skinning (skinning the sorted column) -- Key: TRINIDAD-944 URL: https://issues.apache.org/jira/browse/TRINIDAD-944 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Cristi Toth Priority: Minor Fix For: 1.0.7-core, 1.2.7-core Add skinning keys for the sorted column of a table like: af|column::sorted-header-text; af|column::sorted-header-number; af|column::sorted-header-icon-format; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-944) Improvement of table skinning (skinning the sorted column)
[ https://issues.apache.org/jira/browse/TRINIDAD-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth updated TRINIDAD-944: - Status: Patch Available (was: Open) Improvement of table skinning (skinning the sorted column) -- Key: TRINIDAD-944 URL: https://issues.apache.org/jira/browse/TRINIDAD-944 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Cristi Toth Priority: Minor Fix For: 1.0.7-core, 1.2.7-core Attachments: TRINIDAD-944_sorted_column.patch Add skinning keys for the sorted column of a table like: af|column::sorted-header-text; af|column::sorted-header-number; af|column::sorted-header-icon-format; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-939) shortcut links in Skinning document do not work.
[ https://issues.apache.org/jira/browse/TRINIDAD-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth updated TRINIDAD-939: - Status: Patch Available (was: Open) shortcut links in Skinning document do not work. Key: TRINIDAD-939 URL: https://issues.apache.org/jira/browse/TRINIDAD-939 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.5-core Reporter: Jeanne Waldman Priority: Minor Attachments: TRINIDAD-939_skinning_devguide_toc.patch The skinning doc's table of contents links do not work. http://myfaces.apache.org/trinidad/devguide/skinning.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-945) Improvement of tree skinning (added no-children icon)
[ https://issues.apache.org/jira/browse/TRINIDAD-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth updated TRINIDAD-945: - Status: Patch Available (was: Open) Improvement of tree skinning (added no-children icon) - Key: TRINIDAD-945 URL: https://issues.apache.org/jira/browse/TRINIDAD-945 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Cristi Toth Fix For: 1.0.7-core, 1.2.7-core Attachments: TRINIDAD-945_tree_no-children-icon.patch Add a no-children icon to be rendered instead of expanded/collapsed icons in the case where the node has no children -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-945) Improvement of tree skinning (added no-children icon)
Improvement of tree skinning (added no-children icon) - Key: TRINIDAD-945 URL: https://issues.apache.org/jira/browse/TRINIDAD-945 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Cristi Toth Fix For: 1.0.7-core, 1.2.7-core Add a no-children icon to be rendered instead of expanded/collapsed icons in the case where the node has no children -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] content compression
Hi Matthias, I think it would be great help for developers which first encounter skinning. On Feb 7, 2008 9:47 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I have the feeling that it might be helpful for the demo app to turn content compression OFF! So that you see CSS classes like af_comp_blah instead of xyz. Yes, it is a performance hit, but by default it is enabled (the compression). In the web.xml file, we can add a WARNING like: NEVER have this in production etc.. what are you thinking ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: Got It !!! Re: Tree skinning problem with Trinidad 1.2.5
I'm glad that I could be of some help.
--
Cristi Toth
-
Codebeat
www.codebeat.ro
On Jan 30, 2008 12:52 AM, Frank Nimphius [EMAIL PROTECTED] wrote:
Cristi,
thanks for the pointer to the beach.css. I found a clue that got me going
with
af|tree::node-icon:folder
Frank
Cristi Toth wrote:
As Matthias said, the changes were comitted in december.
And as I said a good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Give more details about your problem so I can help you.
regards,
On Jan 29, 2008 9:33 AM, Frank Nimphius [EMAIL PROTECTED] wrote:
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns folder
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED] wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
Re: Tree skinning problem with Trinidad 1.2.5
As Matthias said, the changes were comitted in december.
And as I said a good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Give more details about your problem so I can help you.
regards,
On Jan 29, 2008 9:33 AM, Frank Nimphius [EMAIL PROTECTED] wrote:
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns folder
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED] wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: Tree skinning problem with Trinidad 1.2.5
Hi
I have refactored the tree skinning in november.
But it was only comitted in the 1.0.* trunk.
I will try to prepare a patch for 1.2.* this week-end.
(hope I'll have some time)
On Jan 23, 2008 8:58 PM, Frank Nimphius [EMAIL PROTECTED] wrote:
Simon,
thanks, I will give the different URL usage a try. Note that I am not
talking about the expanded / disclosed icon, but the folder icon. In ADF
Faces the node icon (disclosed / expanded) is a puls/minus image. That I got
working in Trinidad. However, after that icon in ADF Faces there comes a
folder icon, which I cannot get working in Trinidad though the selector
seems to be there
Frank
Simon Lessard wrote:
Hello Frank,
I see the following selectors in SkinSelectors:
public static final String AF_TREE_EXPANDED_ICON =
af|tree::expanded-icon;
public static final String AF_TREE_COLLAPSED_ICON =
af|tree::collapsed-icon;
So the good skin's CSS value should be:
af|tree::collapsed-icon{content:url('/skins/oracle/images/tfold.gif');}
af|tree::expanded-icon{content:url('/skins/oracle/images/tfold.gif');}
Also note that Trinidad deals with URL differently than ADF Faces so if
the images are in a sub-directory of the folder containing the skin's CSS
file, then you can use relative URL like the following to achieve the same
result.
af|tree::collapsed-icon{content:url('images/tfold.gif');}
af|tree::expanded-icon{content:url('images/tfold.gif');}
Regards,
~ Simon
On Jan 23, 2008 1:45 PM, Frank Nimphius [EMAIL PROTECTED]
wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: Skinning selectors for tree component in Trinidad 1.2.4 missing
Hi all! I added the current tree skinning selectors some months ago. This happened before the decision of letting the comitter to copy changes from 1.0.* to 1.2.* (instead of the one who does the release) I did the changes only for 1.0.* branch and by the lack of time I assumed it was also copied into 1.2.* (sorry for that) I checked and indeed the tree is updated only in 1.0.* branch. The original issue was TRINIDAD-769. I will test the patch provided there with 1.2.* and, if necessary, I will update it. regards, On Jan 10, 2008 7:15 PM, Frank Nimphius [EMAIL PROTECTED] wrote: Hi, I tried to skin the tree component in Trinidad 1.2.4 (trying to show custom icons) and noticed that the renderer for the tree, nor the base renederer class, have any skin selectors defined. The tree table looks fine, so I am wondering what has happened to the skin selectors for the tree. af|tree::collapsed-icon af|tree::expanded-icon af|tree::line-icon af|tree::node-icon Frank -- Frank Nimphius Principal Product Manager Application Development Tools Oracle Corporation mail: [EMAIL PROTECTED] phone:+49 2058 782481 -- Cristi Toth - Codebeat www.codebeat.ro
Re: Server state saving and multiple frames
Hi, anyone is invited to contribute with ideas of course, but I still don't understand what this (multiple-frames state saving) has to do with dialog handling and conversations!? On Dec 20, 2007 9:13 AM, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Nicu, we should include Mario in this discussion - he implemented a solution for this in Orchestra. Also, how about Trinidad, in Trinidad there is dialog handling as well, how is this done? regards, Martin On 12/19/07, simon [EMAIL PROTECTED] wrote: Hi Nicu, I haven't got time to look at this closely, but IMO siomething like this is definitely needed in MyFaces. A user with multiple windows is certainly going to have trouble at the moment. I think a modification to the view pool to include a window id (or frame id) is definitely a good idea. The second part of the problem still remains: how to associate a different id with each window/frame. Checking CommandLink components for a target attribute is clever; it doesn't solve all the cases but does solve some. Regards, Simon On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote: Hi, There is a problem in JSF when more than one window are opened in an application. There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION view states saved at one moment (when server side state saving is enabled). If you have 2 windows opened and you navigate on one of them for NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's state. I've been facing this problem while developing a project so I've implemented a solution for it. The solution is having a number of view states saved for each opened window at one moment. For determining when a new window (frame) is opened, the target of the submitting component (or its enclosing form) is used. This is obtained in the HtmlLinkRendererBase's and HtmlButtonRendererBase's decode methods and it is set in the RequestMap. Using the submitted target, the JspStateManagerImpl figures out whether a new frame was opened. If so, a new frame id is generated. In the renderResponse phase, the frameId is encoded in the javax.faces.ViewState field and is used along with the viewId to save the state in a SerializedViewCollection. In the restore view phase the frameId is decoded from the javax.faces.ViewState field and is used along with the viewId to restore the corresponding state from the SerializedViewCollection. In SerializedViewCollection instead of a list of recently used views, now a list is kept for each frameId. The following context params are defined for configuring this. NUMBER_OF_FRAMES_IN_SESSION (max frames stored) NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame) These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param. What is your opinion on this solution? Of course this solution only works with MyFaces Tomahawk's commandLink and commandButton. Ohter component sets that do not use a custom stateManager might use this feature if they will just modify the renderers of command components to set the target attribute in the requestMap. An extra feature would be to enable this for outputLinks (plain old links) and for JS (openWindow). The solution for this is quite simple, just add a GET parameter named 'target' and set the value the same as the target attribute. In the JspStateManagerImpl this value is obtained from the requestParameterMap and used the same as in the other case. Do you think this would be useful too? Regards, Nicu -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Cristi Toth - Codebeat www.codebeat.ro
Re: Server state saving and multiple frames
this feature if they will just modify the renderers of command components to set the target attribute in the requestMap. An extra feature would be to enable this for outputLinks (plain old links) and for JS (openWindow). The solution for this is quite simple, just add a GET parameter named 'target' and set the value the same as the target attribute. In the JspStateManagerImpl this value is obtained from the requestParameterMap and used the same as in the other case. Do you think this would be useful too? Regards, Nicu -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Cristi Toth - Codebeat www.codebeat.ro
state saving (StateManager) and multiple frames (HACKATHON points 4 and 6)
Hi all! Point 4 on Hackathon list (http://wiki.apache.org/myfaces/Hackathon_2007) : - look at supporting multiple concurrent windows in MyFaceshttp://wiki.apache.org/myfaces/MyFaceswith server-side state. Currently AFAIK there is only one viewstate pool, not one per window, so using one window can force the state backing the other window to be discarded. This may overlap with the externalise view cache proposal currently logged as a JIRA issue. We already started doing this for one of our customers and of course thought that this would be a nice feature to add in MyFaces. The simple solution we thought about consists of the following: - in JspStateManagerImpl : - adding frameId attribute to the protected class SerializedViewKey (similar to the sequenceId attribute) - in the protected class SerializedViewCollection - transforming the _keys list into a matrix, where each line stores the keys corresponding to a frameId - defining a context param DEFAULT_NUMBER_OF_FRAMES_IN_SESSION - changing DEFAULT_NUMBER_OF_VIEWS_IN_SESSION to DEFAULT_NUMBER_OF_VIEWS_FOR_FRAME - in HtmlResponseStateManager - adding an array item containing the frameId to the saveState array (in all the methods) I think this will solve the problem with having multiple frames Then I noticed point 6 on the Hackathon wiki page: - clean up the state-saving code (JsfStateManagerImpl, HtmlResponseStateManager). Currently, every state option has been implemented by adding code to these classes. It would be nice to instead have a separate subclass per strategy; see INIT_PARAM_VIEWSTATE_JAVASCRIPT implementation for an ugly example. This then enables easier implementation/experimentation with new strategies. I totally agree with this. Can you give us some ideas how to decouple this code? And how to add the capability for programmers to change the state saving strategy ? Thanks for any advices, -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Created: (TRINIDAD-769) Tree / TreeTable skinning improvements
Tree / TreeTable skinning improvements -- Key: TRINIDAD-769 URL: https://issues.apache.org/jira/browse/TRINIDAD-769 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Cristi Toth Fix For: 1.0.4-core The tree/treeTable skinning improvements talked about in the mailing list threads :[Trinidad] Skinning the tree, [Trinidad] tree components skinning improvement To the tree skinning: - the connecting lines (with possibility to skin / disable them) - the possibility to skin the expand/collapse icon - the possibility to add node icons with a String getNodeType() method in the node class For the tree table: - the same things except the lines - possibility to skin the expand all / collapse all icons -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-769) Tree / TreeTable skinning improvements
[ https://issues.apache.org/jira/browse/TRINIDAD-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cristi Toth updated TRINIDAD-769: - Status: Patch Available (was: Open) Tree / TreeTable skinning improvements -- Key: TRINIDAD-769 URL: https://issues.apache.org/jira/browse/TRINIDAD-769 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Cristi Toth Fix For: 1.0.4-core The tree/treeTable skinning improvements talked about in the mailing list threads :[Trinidad] Skinning the tree, [Trinidad] tree components skinning improvement To the tree skinning: - the connecting lines (with possibility to skin / disable them) - the possibility to skin the expand/collapse icon - the possibility to add node icons with a String getNodeType() method in the node class For the tree table: - the same things except the lines - possibility to skin the expand all / collapse all icons -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Announce] Release of Apache MyFaces Orchestra 1.0
Yeah, congratulations to the whole Orchestra team !!! Very nice work! It's something already long expected ;) On 10/13/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/12/07, Dan Tran [EMAIL PROTECTED] wrote: when do we expect to see orchestra-core-1.0 at repo1.maven.org/maven2 ? dont see it there yet!! I pinged the repository list to ask someone to check on the sync. -- Wendy -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] panelTabbed skinning improvement
Hmm, I thought there is a config file where you can specifiy these renderers. Anyway I'm sure that it's better to just refactor the whole panelTabbed renderer. On 10/9/07, Andrew Robinson [EMAIL PROTECTED] wrote: I did it with a custom view handler via the Java API, I never bothered with registering it. org.apache.myfaces.trinidadinternal.ui.RendererFactoryImpl factory = (org.apache.myfaces.trinidadinternal.ui.RendererFactoryImpl )org.apache.myfaces.trinidadinternal.ui.RendererManager .getDefaultRendererManager() .getFactory( org.apache.myfaces.trinidadinternal.ui.UIConstants.MARLIN_NAMESPACE); factory.registerRenderer( org.apache.myfaces.trinidadinternal.ui.UIConstants.SUB_TAB_BAR_NAME, new SubTabBarRenderer()); On 10/9/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi Andrew! Sounds good, but can you tell me how can I override the default SubTabBarRenderer? I have no idea where the mapping is done for 'sub renderers' from the uix/ui packages. I hope this can be done without me needing to overwrite the default renderer in the trinidad sources and build them myself. thanks On 10/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have submitted such an issue that keeps the existing tabs and adds the new ones. This way it is backwards compatible. https://issues.apache.org/jira/browse/TRINIDAD-632 On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi! The skinning of the pannelTabbed component could be improved so that it can have round cornered tabs (like in most of the applications), similar to navigationPanel with hint=tabs but simpler. My opinion is to have the following selectors: af:panelTabbed:: - beforeCell (-selected) - cell (-selected) - afterCell (-selected) - separatorCell This way it would be skinnable very nice. BUT... what to do for backwards compatibillity? -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] panelTabbed skinning improvement
Hi Andrew! Sounds good, but can you tell me how can I override the default SubTabBarRenderer? I have no idea where the mapping is done for 'sub renderers' from the uix/ui packages. I hope this can be done without me needing to overwrite the default renderer in the trinidad sources and build them myself. thanks On 10/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: I have submitted such an issue that keeps the existing tabs and adds the new ones. This way it is backwards compatible. https://issues.apache.org/jira/browse/TRINIDAD-632 On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi! The skinning of the pannelTabbed component could be improved so that it can have round cornered tabs (like in most of the applications), similar to navigationPanel with hint=tabs but simpler. My opinion is to have the following selectors: af:panelTabbed:: - beforeCell (-selected) - cell (-selected) - afterCell (-selected) - separatorCell This way it would be skinnable very nice. BUT... what to do for backwards compatibillity? -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] treeTable improvements + fix
Hi all! I'm currently working on the treeTable rendering / skinning and I some improvements / fixes in mind. First I noticed that the row banding doesn't work right. at each deeper level (expanded node) it resets the banding to 0 meaning the each first child node starts with the first color (no matter what color is the previous row) Am I wrong? If not, I'll try and fix this. Improvements: Some people need to be able to hide the breadCrumbs and the focus column, because they don't need it. I thought that it would be nice to have a parameter 'focusingEnabled' with the default value to true And if it's set to false, to hide the breadcrumbs row and the focus component. What do you say? -- Cristi Toth - Codebeat www.codebeat.ro
[Trindiad] breadCrumbs skinning improvement
Hi! I hava an improvement idea on the breadCrumbs skinning. When the orientation is set to vertical, in other applications, the separator is just before the text entry a line corner (like the last node of a tree) But this means that we need to be able to put the separator icon in front of the text. So I thought to add a skinning property '-tr-breadCrumbs-separator-position' with the possible values 'before' or 'after' What do you say? -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] panelTabbed skinning improvement
Hi! The skinning of the pannelTabbed component could be improved so that it can have round cornered tabs (like in most of the applications), similar to navigationPanel with hint=tabs but simpler. My opinion is to have the following selectors: af:panelTabbed:: - beforeCell (-selected) - cell (-selected) - afterCell (-selected) - separatorCell This way it would be skinnable very nice. BUT... what to do for backwards compatibillity? -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] tree components skinning improvement
Hi! I already did some work on the tree components: I added the lines to the tree and the capability to skin the expand / collapse icons. But normal trees also have some different icons for each node (next to the expand/collapse icon) In tomahawk, each node has a sting property named 'type' which is then used to define facets with that name and inside you can render icons or whatever. This way you can put for each node type an icon. I thought that in trinidad I could just use that 'type' attribute to get the icon from the skin so there'll be icon skinSelectors like : af|tree::node-icon:type type beeing the value of the 'type' parameter. There are 2 ways of doing this. 1. add the optional property to the tree node class 2. extend the tree node class and add the property Which one do you suggest? -- Cristi Toth - Codebeat www.codebeat.ro
[Trinidad] skinning TEXT keys documentation missing?
Hi! I'm using skinning to have internationalized components (with my bundle) and I noticed there's absolutely no documentation about this. So you have to look into the renderers to find this info. And in most of them the strings aren't even declared as constants. Is there somewhere a hidden documentation? If not we should open a JIRA issue for this. -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] skinning TEXT keys documentation missing?
Thanks Jeanne, I figured that too and I also look in the renderers. It's not that hard for me, but I'm sure it is for the usual user. On 10/9/07, Jeanne Waldman [EMAIL PROTECTED] wrote: The hidden documentation is 1. look at the trinidad-skins.xml document in the demo. You'll set bundle-name. 2. The keys are in CoreBundle.xrts. Not documented officially. - Jeanne Danny Robinson wrote: Cristi, Please can you raise an issue for this. Thanks, D. On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi! I'm using skinning to have internationalized components (with my bundle) and I noticed there's absolutely no documentation about this. So you have to look into the renderers to find this info. And in most of them the strings aren't even declared as constants. Is there somewhere a hidden documentation? If not we should open a JIRA issue for this. -- Cristi Toth - Codebeat www.codebeat.ro -- Chordiant Software Inc. www.chordiant.com -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] navigationTree not refactored???
Hi Adam! No problem, I'll do it. But I need to know some start points... i.e. It took me some 1/2 hour to figure that the actual renderer that does the job is the NavigationTreeRenderer from ui.laf.desktop package not the close to useless one from the uix package. Is something from the uix package classes really needed in this case? Should I rely on the old ComandNavigationRenderer or refactor that too? Please tell from where to start (so I don't loose to much time) and what things should I look for (not to mess it up). I really need this and I have a very short time for this. (wednesday at noon) On 10/9/07, Adam Winer [EMAIL PROTECTED] wrote: It's desperately in need of refactoring to extend off of the new TreeRenderer, and not the old 'uix' one. -- Adam On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi all! I need I really need the navigationTree and I noticed the renderer is still in the 'uix' package and that the code is... still old style and I don't understand nothing. It's extremely short and I didn't figure it out where's all the rendering implemented. Can somebody help me with some hints? I would like to refactor it and enhance its skinning (which for now seems to be disabled) -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Created: (TRINIDAD-759) skinning TEXT keys documentation missing
skinning TEXT keys documentation missing Key: TRINIDAD-759 URL: https://issues.apache.org/jira/browse/TRINIDAD-759 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation, Skinning Affects Versions: 1.0.4-core Reporter: Cristi Toth There is no documentation on the TEXT keys (from the skin bundles) used for skinning the components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Skinning the tree
On 9/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Cristi Toth wrote:
Hi all,
I've done some work on the tree renderer in Trinidad
I added the connecting lines, like in Tomahawk (or any other tree) behind
the expanded/collapsed icon (-, +)
I now have 5 skin-selectors for the tree:
af|tree::expanded-icon
af|tree::collapsed-icon
- these are the [-], [+] icons
af|tree::line-icon - this one is the vertical line
af|tree::line-middle-icon - this one is the horizontal line for each entry
(used in the back of the expanded/collapsed icon)
af|tree::line-last-icon - this one is like the one above, but it is used
in the case of the last sibling (the corner)
now some questions:
1) should I add a 'renderLines' attribute to the 'tree' component to
enable/disable the lines ?
I would make this a skin property, not a per instance component property.
Something like:
af|tree { -tr-render-lines: true}
Sounds better indeed!
2) should I let the lines be skinnable and add them to the base skin?
it's up to you. Showing/hiding them with the skin property probably is
enough.
So you think it's useless to make the lines skinnable? (sounds fine with me)
3) if I let them be skinnable, then should I ommit the 'renderLines' attr
and let the user just override the line icons with blank ones?
again, I think this should be a skin property.
Next, I worked on the TreeTable renderer. I made the 'Expand All /
Collapse All' links skinnable.
1. should I move the the 'Expand All / Collapse All' links on the first
row and get rid of the 2nd ?
It seems quite useless to have 2 rows
not sure what you mean.
If you look in the screen-shot at the treeTable on the 2nd row there are
the 'expand all/collapse all' links.
I think they would fit perfectly on the first row (along the previous /
next) and to get rid of the 2nd row (subControlBar)
2. should I also make the focus link 'X' skinnable (it looks kind of lame
right now) ?
sure. I'm surprised it isn't already.
3. should I add some attributes for disabling the focus column and the
breadCrumbs, for people who don't need them?
4. I noticed a bug in the row banding, it's not correctly rendered, I
suppose it would be nice if I fix it...
You can see here a pictures with the results of what I did until now:
http://people.apache.org/~ckormos/tree_skinning.pnghttp://people.apache.org/%7Eckormos/tree_skinning.png
Is this welcomed by you guys?
I like it.
regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Thanks for the feedback!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
[Trinidad] Skinning the tree
Hi all, I've done some work on the tree renderer in Trinidad I added the connecting lines, like in Tomahawk (or any other tree) behind the expanded/collapsed icon (-, +) I now have 5 skin-selectors for the tree: af|tree::expanded-icon af|tree::collapsed-icon - these are the [-], [+] icons af|tree::line-icon - this one is the vertical line af|tree::line-middle-icon - this one is the horizontal line for each entry (used in the back of the expanded/collapsed icon) af|tree::line-last-icon - this one is like the one above, but it is used in the case of the last sibling (the corner) now some questions: 1) should I add a 'renderLines' attribute to the 'tree' component to enable/disable the lines ? 2) should I let the lines be skinnable and add them to the base skin? 3) if I let them be skinnable, then should I ommit the 'renderLines' attr and let the user just override the line icons with blank ones? Next, I worked on the TreeTable renderer. I made the 'Expand All / Collapse All' links skinnable. 1. should I move the the 'Expand All / Collapse All' links on the first row and get rid of the 2nd ? It seems quite useless to have 2 rows 2. should I also make the focus link 'X' skinnable (it looks kind of lame right now) ? 3. should I add some attributes for disabling the focus column and the breadCrumbs, for people who don't need them? 4. I noticed a bug in the row banding, it's not correctly rendered, I suppose it would be nice if I fix it... You can see here a pictures with the results of what I did until now: http://people.apache.org/~ckormos/tree_skinning.png Is this welcomed by you guys? regards, -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] Skining - strange default value in: base-desktop.xss
Hello Simon,
It would be great if that would be done!
I think others may agree with this too.
Thanks,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/16/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Cristi,
Although maybe we should deal with that issue, they way you used skin
additions is not what it was meant to be at first. Normally skin additions
should be used to extend the selector set of another existing skin, like
when adding new components, not CSS splitting. Therefore, skin additions
should not be overlapping most of the times. There might still be an issue
if we have the following case:
SimpleSkin + SimpleSkinAddition
|
|
CustomSkin + CustomSkinAddition
In that case, CustomSkinAddition should indeed have priority over
SimpleSkinAddition. That being said, I would not be all against allowing
SkinAddition to be used for file splitting.
Regards,
~ Simon
On 8/15/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi Jeane!
The problem is that I need to split the skin style-sheet into more files
because it's getting huge and harder to maintain
So I'm using skin-additions.
And the property from the skin-addition is always overriden by the base
skin.
I really think that the skin-addition should have the same priority as
the skin-extension
here's a snippet from my trinidad-skins file:
skins xmlns= http://myfaces.apache.org/trinidad/skin;
skin
idaaadesktop/id
familyaaa/family
render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id
style-sheet-namecss/aaa.css/style-sheet-name
/skin
skin-addition
skin-idaaa.desktop/skin-id
style-sheet-namecss/layout.css/style-sheet-name
/skin-addition
/skins
and here's a piece from the skin-addition's style sheet:
general-block {
padding: 0px;
margin: 0px;
border: 0px;
}
base-block {
-tr-rule-ref: selector(AFMediumBackground:alias);
-tr-rule-ref: selector(AFDefaultFontFamily:alias);
-tr-rule-ref: selector(AFDefaultFont:alias);
-tr-rule-ref: selector(general-block);
width: 100%;
height: 100%;
}
html {
-tr-rule-ref: selector(base-block);
}
body {
-tr-rule-ref: selector(base-block);
-tr-inhibit: margin-top;
overflow: hidden;
}
and here's a piece from the generated CSS:
general-block {padding:0px;margin:0px;border:0px}
base-block,html {background-color:#EBF0F5;font-family:Arial, Helvetica,
sans-serif;font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%}
body {background-color:#EBF0F5;font-family:Arial, Helvetica, sans-serif;
font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%;overflow:hidden;
margin-top:8px}
thanks for help!
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/15/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Can you send me a simple test case for this scenario so I can see if
it is a bug or you are not
implementing it correctly.
What should be happening is we read the base skin in and merge in the
skin extension after.
The skin extensions css properties take precedence. They extend the
base skin's properties.
When we write out the css-2 stylesheet, we have a performance step
where we group all the
selectors with the same css properties together. This will then appear
to be reordering the properties.
Instead of the selectors being generated in the order you wrote them:
.af_foo {font-size: 8px; color: red; font-weight: bold; font-style:
italic; font-family: Tahoma}
.af_bar {font-size: 12px; color: black; border-width: 1px}
.af_zoo {font-size: 8px; color: red; font-weight: bold; font-style:
italic; font-family: Tahoma}
.af_xyz {color: red}
.af_abc {font-size: 12px; color: black; border-width: 1px}
You'll see them grouped together:
.af_foo, .af_zoo {font-size: 8px; color: red; font-weight:
bold;font-style: italic; font-family: Tahoma}
.af_bar, .af_abc {font-size: 12px; color: black; border-width: 1px}
.af_xyz {color: red}
- Jeanne
Cristi Toth wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the
same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the
skin,
it is still
[Trinidad] Skining - strange default value in: base-desktop.xss
Hi Jeane!
The problem is that I need to split the skin style-sheet into more files
because it's getting huge and harder to maintain
So I'm using skin-additions.
And the property from the skin-addition is always overriden by the base
skin.
I really think that the skin-addition should have the same priority as the
skin-extension
here's a snippet from my trinidad-skins file:
skins xmlns= http://myfaces.apache.org/trinidad/skin;
skin
idaaadesktop/id
familyaaa/family
render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id
style-sheet-namecss/aaa.css/style-sheet-name
/skin
skin-addition
skin-idaaa.desktop/skin-id
style-sheet-namecss/layout.css/style-sheet-name
/skin-addition
/skins
and here's a piece from the skin-addition's style sheet:
general-block {
padding: 0px;
margin: 0px;
border: 0px;
}
base-block {
-tr-rule-ref: selector(AFMediumBackground:alias);
-tr-rule-ref: selector(AFDefaultFontFamily:alias);
-tr-rule-ref: selector(AFDefaultFont:alias);
-tr-rule-ref: selector(general-block);
width: 100%;
height: 100%;
}
html {
-tr-rule-ref: selector(base-block);
}
body {
-tr-rule-ref: selector(base-block);
-tr-inhibit: margin-top;
overflow: hidden;
}
and here's a piece from the generated CSS:
general-block {padding:0px;margin:0px;border:0px}
base-block,html {background-color:#EBF0F5;font-family:Arial, Helvetica,
sans-serif;font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%}
body {background-color:#EBF0F5;font-family:Arial, Helvetica, sans-serif;
font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%;overflow:hidden;
margin-top:8px}
thanks for help!
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/15/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Can you send me a simple test case for this scenario so I can see if it
is a bug or you are not
implementing it correctly.
What should be happening is we read the base skin in and merge in the skin
extension after.
The skin extensions css properties take precedence. They extend the base
skin's properties.
When we write out the css-2 stylesheet, we have a performance step where
we group all the
selectors with the same css properties together. This will then appear to
be reordering the properties.
Instead of the selectors being generated in the order you wrote them:
.af_foo {font-size: 8px; color: red; font-weight: bold; font-style: italic;
font-family: Tahoma}
.af_bar {font-size: 12px; color: black; border-width: 1px}
.af_zoo {font-size: 8px; color: red; font-weight: bold; font-style: italic;
font-family: Tahoma}
.af_xyz {color: red}
.af_abc {font-size: 12px; color: black; border-width: 1px}
You'll see them grouped together:
.af_foo, .af_zoo {font-size: 8px; color: red; font-weight: bold;font-style:
italic; font-family: Tahoma}
.af_bar, .af_abc {font-size: 12px; color: black; border-width: 1px}
.af_xyz {color: red}
- Jeanne
Cristi Toth wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the
same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the
skin,
it is still overwritten by the instance in base-desktop.xss, which is last
(so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current project! (I
can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi!
I found a strange default value for IE browser: body { margin-top: 8px }
in base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Skinning] independent MyFaces skinning module
hi there's a utility class in tomahawk: AddResource I use that like this: AddResource addResource = AddResourceFactory.getInstance(context); addResource.addStyleSheet(context, AddResource.HEADER_BEGIN, uri); regards, Cristi Toth - Codebeat www.codebeat.ro On 8/13/07, Leonardo Uribe [EMAIL PROTECTED] wrote: Another question. How do you register the css file in a web page? I doing this using trh:stylesheet component, but I could be better if this is registered using some api on myfaces to register resources. I suppose that you define a component for doing this. regards Att: Leonardo Uribe --
Re: [Trinidad] Skining - strange default value in: base-desktop.xss
Hi Simon,
I know the -tr-inhibit property,
BUT the base skin style-sheet seems to be added last
so the nodes form it always override the nodes in me style-sheet
even if I use -tr-inhibit
This is exactly what you said in the code I mentioned before.
You never know which one has the priority :(
regards,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Cristi,
I had that discussion a while back during incubation. I would also like a
very light (empty) base skin and we're actually going to make one for a
project. It's already possible by extending simple, overriding every single
selectors and add a -tr-inhibit: all;, effectively disabling all aliases
as well. I do think many users could like to have such a skin to extend from
and I'm going to ask the project manager to donate the empty skin once it's
done.
Regards,
~ Simon
On 8/9/07, Cristi Toth [EMAIL PROTECTED] wrote:
Ok... I thought that using a skin that extends no base skin or a very
basic (empty) one would do the trick
But I found out that the most basic one is the SimpleDesktopSkin which
includes that huge base-desktop.xss
I can understand that it is ok to have a good default skin
But shouldn't it be a way to just use an EMPTY BASE SKIN ?
Regards,
Cristi Toth
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the
same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the
skin,
it is still overwritten by the instance in base-desktop.xss, which is
last (so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current project!
(I can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi!
I found a strange default value for IE browser: body { margin-top:
8px } in base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] Skining - strange default value in: base-desktop.xss
the thing is that the order in which the nodes are handled is very important
the base skin style-sheet should be the first
and the custom style-sheet should be the last
this way any property inhibit or override should work as needed
it's useless to load all the properties and then apply the tr-inhibit
because my property will still be overwritten by that in the base-skin
and the tr-inhibit will inhibit ANY property definition
the big problem is in the order the style-sheets are handled
regards,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/11/07, Simon Lessard [EMAIL PROTECTED] wrote:
Yeah I remember that comment that I put there. I'll check it again, see
what would be the impact of loading everything before doing inhibit and
probably fill a JIRA issue about this.
~ Simon
On 8/11/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi Simon,
I know the -tr-inhibit property,
BUT the base skin style-sheet seems to be added last
so the nodes form it always override the nodes in me style-sheet
even if I use -tr-inhibit
This is exactly what you said in the code I mentioned before.
You never know which one has the priority :(
regards,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Cristi,
I had that discussion a while back during incubation. I would also
like a very light (empty) base skin and we're actually going to make one
for
a project. It's already possible by extending simple, overriding every
single selectors and add a -tr-inhibit: all;, effectively disabling all
aliases as well. I do think many users could like to have such a skin to
extend from and I'm going to ask the project manager to donate the empty
skin once it's done.
Regards,
~ Simon
On 8/9/07, Cristi Toth [EMAIL PROTECTED] wrote:
Ok... I thought that using a skin that extends no base skin or a
very basic (empty) one would do the trick
But I found out that the most basic one is the SimpleDesktopSkin
which includes that huge base-desktop.xss
I can understand that it is ok to have a good default skin
But shouldn't it be a way to just use an EMPTY BASE SKIN ?
Regards,
Cristi Toth
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line
477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a
selector / element in a 'random' order
and the properties in the first instances are being overwritten by
the same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the
skin extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in
the skin,
it is still overwritten by the instance in base-desktop.xss, which
is last (so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current
project! (I can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi!
I found a strange default value for IE browser: body {
margin-top: 8px } in base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Skinning] independent MyFaces skinning module
well, I used a ViewHandler which initialized the skinning but Martin told me that for PPR rendering purposes I should do it from the renderers and I'm not using a Filter (like the trinidad filter) I'm really busy these days, but I'll do my best to finish it until next week and post it somewhere regards, Cristi Toth - Codebeat www.codebeat.ro On 8/9/07, Leonardo Uribe [EMAIL PROTECTED] wrote: Thinking about this topic, Cristi, are you implementing a custom ViewHandler and a Filter to initialize skin code, and using a RenderKit that have the initialization code using the interface ExtendedRenderKitService? I feel very curious about how are you doing this. regards Att: Leonardo Uribe
[Trinidad] Skining - strange default value in: base-desktop.xss
Hi!
I found a strange default value for IE browser: body { margin-top: 8px } in
base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] Skining - strange default value in: base-desktop.xss
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the same
properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the skin,
it is still overwritten by the instance in base-desktop.xss, which is last
(so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current project! (I
can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi!
I found a strange default value for IE browser: body { margin-top: 8px }
in base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Re: [Trinidad] Skining - strange default value in: base-desktop.xss
Ok... I thought that using a skin that extends no base skin or a very basic
(empty) one would do the trick
But I found out that the most basic one is the SimpleDesktopSkin which
includes that huge base-desktop.xss
I can understand that it is ok to have a good default skin
But shouldn't it be a way to just use an EMPTY BASE SKIN ?
Regards,
Cristi Toth
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the
same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the
skin,
it is still overwritten by the instance in base-desktop.xss, which is last
(so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current project! (I
can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth [EMAIL PROTECTED] wrote:
Hi!
I found a strange default value for IE browser: body { margin-top: 8px }
in base-desktop.xss
on line 3943:
styleSheet browsers=ie
style selector=body
property name=margin-top8px/property
/style
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Skinning] independent MyFaces skinning module
Hi Jeanne, I'm really glad that you're interested! I know that you have great experience in skinning and that you know the code well. I'd love to cooperate with you to make this really work nice. Now, I'm still working on some small things, before I'll make the code public. I'm hurrying (even if I'm really busy these days) best regards, Cristi Toth - Codebeat www.codebeat.ro On 8/2/07, Jeanne Waldman [EMAIL PROTECTED] wrote: I'd love to have an independent skinning module that all renderers can use. We'll need a good plan on how we want to break this up and what APIs we have available for the renderers, what's public, what's private, how it works for pda, for portal, etc. We also need to put in place lots of tests so that we can ensure we don't break anything. Right now I do manual testing -- I run the app in a couple different skins and save the css file. Then before I check in I run the skins again and compare the css files. I do this in compressed and uncompressed modes. I'd love it if we have some automated tests so that we don't break skinning as we are refactoring it. One feature I think we need is an API for the renderer to be able to 'map' a skin selector to something else -- like af|foo::bar-link could map to af|foo::bar A. We don't want to expose af|foo::bar A as a public skin selector because it shows the implementation of the renderer. Right now we do this in FileSystemStyleCache, and that's obviously not a good way to do it. Anyway... that's on my list. Cristi, I'm interested to see what you have done. - Jeanne Simon Lessard wrote: Hello Cristi, It would sure be nice to have an independent common skinning module for custom component libraries. However, I wonder what version of the skinning module you used and how you handled dependencies while refactoring it because there's many changes with skinning with every releases. Regards, ~ Simon On 7/30/07, *Cristi Toth* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all! I just finished my diploma project on Skinning in MyFaces More exactly, what I did is refactoring out Trinidad's skinning feature into an independent module I also did a small and simple module that adds this feature to Tomahawk. It's very simple to use. It is intended to demonstrate how easy is to add skinning features to any component-set In the skinning module I tried to refactor and simplify the old Trinidad code behind. But there is some more work to do. So how do you think this would be usable to MyFaces? I mean what should I do now to get this code used and improved by the community? Wouldn't be nice to try to make Trinidad use this module and get rid of the skinning code from it? I'm waiting forward to your feedBack Best regards, Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro
Re: [Skinning] independent MyFaces skinning module
well, I refactored the old RenderingContext into more simple classes and with a lot less dependencies my approach was also Decorating existing renderers but for Tomahawk, I did one generic Renderer for all components, based on reflection it just searches for any Class' or 'StyleClass' ending properties in the component and if it finds them then it searches for their name in the defined selectors and sets the appropriate styleClasses into the component it is really important to have the skinning independent, because one that uses tomahawk, might not want to have trinidad dependencies and this module could be adapted to ANY component set but there's still a lot to refactor in that skinning code I still have some minor things to do that Martin Marinscheck suggested, just to be sure that it's compatible with everything and that in the near future Trinidad can use this too well unfortunately, I haven't done any serious documentation, because I was really in a hurry but I'm prepared to do it and afterwards discuss with you guys what to do next thanks for the replies Best regards, Cristi Toth - Codebeat www.codebeat.ro On 8/1/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: right, also, do you've documentation already ? On 7/31/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Cristi, It would sure be nice to have an independent common skinning module for custom component libraries. However, I wonder what version of the skinning module you used and how you handled dependencies while refactoring it because there's many changes with skinning with every releases. Regards, ~ Simon On 7/30/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi all! I just finished my diploma project on Skinning in MyFaces More exactly, what I did is refactoring out Trinidad's skinning feature into an independent module I also did a small and simple module that adds this feature to Tomahawk. It's very simple to use. It is intended to demonstrate how easy is to add skinning features to any component-set In the skinning module I tried to refactor and simplify the old Trinidad code behind. But there is some more work to do. So how do you think this would be usable to MyFaces? I mean what should I do now to get this code used and improved by the community? Wouldn't be nice to try to make Trinidad use this module and get rid of the skinning code from it? I'm waiting forward to your feedBack Best regards, Cristi Toth - Codebeat www.codebeat.ro -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Skinning] independent MyFaces skinning module
Well the nice thing was that I don't need to define the selectors statically somewhere f.e. the selectors for tomahawk are made on this rule: mf|fully_qualified_component_Class::style_property_name:css_pseudo_class mf - is the prefix from MyFaces fully_qualified_component_Class - is the full class name with the '.' replaced with _ style_property_name - is the property name without the 'Class' / 'StyleClass' suffix css_pseudo_class - is a normal css pseudo class i.e. ':hover' here are some examples: mf|org_apache_myfaces_component_html_ext_HtmlDataTable::header mf|javax_faces_component_html_HtmlCommandLink:hover well, first this solution is not perfect but it already offers very much of the functionality for EVERY COMPONENT you can also extend the Renderer for particular components about the properties ending in Class but not being a StyleClass property the only thing you shouldn't do is declare that selector in the skin about properties with style classes list (rowClasses, columnClasses) it's very simple : you can define the selectors with the suffix rowClass1,rowClass2, ... for any uncommon skinning behavior, you just have to extend the base renderer thanks for info / questions Cristi Toth - Codebeat www.codebeat.ro On 8/1/07, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi Cristi In order to give you feedback, and gain some feedback too, I have some comments and questions about this topic: You wrote: my approach was also Decorating existing renderers but for Tomahawk, I did one generic Renderer for all components, based on reflection it just searches for any Class' or 'StyleClass' ending properties in the component and if it finds them then it searches for their name in the defined selectors and sets the appropriate styleClasses into the component It sounds good, I started doing something similiar, but there are some components that use class ending properties for another uses different to CSS classes. By example: - s:graphicImage ( imageRendererClass ) - s:outputLinkDynamic ( resourceRendererClass ) Fortunately, only these two components have this problem. The question is how to avoid use this fields as CSS class properties? I have found other things like this: Suppose you want to skin properties in h:dataTable like rowClasses and columnClasses. The first approach is doing the same like in other properties. But It has its drawbacks. This properties are a list of comma separated CSS classes. How do you plan to skin this? Take a look at t:column and t:columns component. This component does not have a renderer!!!. You have to put the code inside the class that decorate the render of t:dataTable and s:autoUpdateDataTable. How to skin this component? And the final question: How do you find the selector? how a component selector looks like? I hope that this contribute to you project. regards Att: Leonardo Uribe
Re: [Skinning] independent MyFaces skinning module
smart boy, you figured it out
yes, I try to get the translated styleClass and if I don't get anything, I
do nothing
about ..Classes properties
as mentioned above I try to get 'rowClass1', 'rowClass2' and so on until I
don't get the translated styleClass
about registering renderers
well, I have a full delegating RenderKit
but I'm still working on how to add it
because I have to let the user define it's own render-kit and then decorate
it
I still have some small things to do
after that, I'll put the sources in a public place so everybody can
contribute
regards,
Cristi Toth
-
Codebeat
www.codebeat.ro
On 8/2/07, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi Cristi!
Here are some comments about this:
Well the nice thing was that I don't need to define the selectors
statically somewhere
f.e. the selectors for tomahawk are made on this rule:
mf|fully_qualified_component_Class::style_property_name:css_pseudo_class
I get to the same selector solution at start of my project too, I say this
to my graphical designer, but he doesn't understand this, because is too
much complicated to do something like this in my case:
af|javax_faces_component_html_HtmlOutputText::style:hover{
}
if is a tomahawk component:
af|org_apache_myfaces_component_html_ext_HtmlOutputText::style {
}
But the designer see in the jsp something like this
h:outputText . /
or
t:outputText . /
He had to ask me every time for each component what is the selector, and
look through tomahawk code
for the correct class name. It could be more clear if you can do this:
h|outputText::style
{
}
But you have to create one class per component that looks something like
this:
package org.apache.myfaces.custom.skin.html ;
import org.apache.myfaces.custom.skin.AdapterSkinRenderer;
public class HtmlOutputTextSkinRenderer extends AdapterSkinRenderer
{
public HtmlOutputTextSkinRenderer()
{
super(h, outputText);
}
}
Note that the price for an increase of code is very low, compared with the
easy of use and speed of code for my designer.
Note that this is my point of view, not the absolute truth.
about the properties ending in Class but not being a StyleClass property
the only thing you shouldn't do is declare that selector in the skin
So you hacked the map that contains the skin selectors (in the original
Skin implementation of trinidad hide this map) and I suppose that you can
find the selectors mapped to a specific component ?. or you call to a class
that works like RenderingContext like this:
styleClass = arc.getStyleClass(selector);
And if does not return anything you don't set the property through
reflection?
about properties with style classes list (rowClasses, columnClasses)
it's very simple : you can define the selectors with the suffix
rowClass1,rowClass2, ...
Cool idea! But for doing this you have to search through the selectors
that matches for an specific component (this feature is not inside trinidad
skin implementation)? How you are doing this?
for any uncommon skinning behavior, you just have to extend the base
renderer
How do you register the extended the base renderer? How does he call to
the base renderer in tomahawk?
Sorry if I ask many questions but I want to do the best for the community
(and for my projects too!!). If you could publish your code with Apache
2.0 license, It would be nice ;)
regards
Att: Leonardo Uribe
--
Cristi Toth
-
Codebeat
www.codebeat.ro
[Skinning] independent MyFaces skinning module
Hi all! I just finished my diploma project on Skinning in MyFaces More exactly, what I did is refactoring out Trinidad's skinning feature into an independent module I also did a small and simple module that adds this feature to Tomahawk. It's very simple to use. It is intended to demonstrate how easy is to add skinning features to any component-set In the skinning module I tried to refactor and simplify the old Trinidad code behind. But there is some more work to do. So how do you think this would be usable to MyFaces? I mean what should I do now to get this code used and improved by the community? Wouldn't be nice to try to make Trinidad use this module and get rid of the skinning code from it? I'm waiting forward to your feedBack Best regards, Cristi Toth - Codebeat www.codebeat.ro
