The problem is that approx 50% of firefox users use 1.5 and the other
50% use 2, about 0% use FF3. No one is on IE 3 yet. (not counting
developers)
-Andrew
On Fri, Apr 25, 2008 at 11:04 AM, Scott O'Bryan [EMAIL PROTECTED] wrote:
I like Matt's idea personally.
Scott
Andrew Robinson wrote
IE 8 not 3. Was still thinking FF3.
On Fri, Apr 25, 2008 at 11:26 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
The problem is that approx 50% of firefox users use 1.5 and the other
50% use 2, about 0% use FF3. No one is on IE 3 yet. (not counting
developers)
-Andrew
On Fri, Apr 25
..
I'm of the opinion that the people who really care about eye candy will have
a more up to date browser. And besides, this is a technical demo, there are
developers and PM's who will be looking at it.
Scott
Andrew Robinson wrote:
The problem is that approx 50% of firefox users use 1.5
Actually FF3 doesn't support it
Go to this in FF3:
http://www.w3.org/Style/Examples/007/roundshadow2.html
No borders :(
-Andrew
On Fri, Apr 25, 2008 at 11:31 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
IE 8 not 3. Was still thinking FF3.
On Fri, Apr 25, 2008 at 11:26 AM, Andrew Robinson
(with CSS3) support shadows?
Glauco P. Gomes
Andrew Robinson escreveu:
This has nothing to do with the demo. I am asking about the new
myfaces skin which users will be able to create their applications
using it.
-Andrew
On Fri, Apr 25, 2008 at 11:35 AM, Scott O'Bryan [EMAIL PROTECTED] wrote
/
Regards,
Matt
On Fri, Apr 25, 2008 at 1:45 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Well, they support multiple background images for an HTML element, so
that you can do rounded corners manually with shadows but not have to
add extra HTML elements to make it possible
PROTECTED] wrote:
+1 to skining selectors.
It's more flexible, and if the user/developer/designer prefer CSS3, he/she
can use without problems.
Glauco P. Gomes
Andrew Robinson escreveu:
While that produces a plain rounded border, it would not allow us to
use
Forgot to ask, this uses annotations for JSF = 1.2 right?
Also one more question, would Jsf* be better than JSF* for the names
(ie JsfProperty vs JSFProperty)? Using all uppercase for an acronym in
a java name is not conventional. Uppercase is usually reserved for
starting a new, unabbreviated
Just out of curiosity, why are we bothering to support a browser that
is discontinued by Microsoft and doesn't even get security patches
anymore? I would think the minimum IE version for all MyFaces projects
should be no earlier than 6.0sp1 to keep in sync. with the current
Microsoft support.
Components: Plugins
Affects Versions: 1.2.7-core, 1.0.7-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
The maven-faces-plugin has two xsl files, transform.xsl and transform12.xsl.
These files are used to build the final version of the faces
Looking at the many of the renderers for Trinidad components I do not
see a lot of skinning selectors that would enable rounded corners. For
example, the panelTabbed has some nice selectors for the tabs, but
only one selector for the body, so it would not be possible to round
the body corners,
[
https://issues.apache.org/jira/browse/TRINIDAD-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591685#action_12591685
]
Andrew Robinson commented on TRINIDAD-1055:
---
Assigning this to me to have
Before I vote, I am curious to know if there has been an audit of the
functionality compared to the maven-faces-plugin tool.
I am wondering about that I can think of right now:
1. component, facet and property meta data extensions that live in
faces-config.xml
2. importing of code from shared
Sounds like fun, but I've already put enough on my plate :) Perhaps in
the future.
On Wed, Apr 23, 2008 at 4:45 PM, Gerhard Petracek
[EMAIL PROTECTED] wrote:
hello,
'sev-en' is just the intermediate (code-)name - let's find a final name.
there will be some modules within commons-[new name]
+0.5 to the code
-0.9 as a new top level project. I really would prefer to see this in
commons or orchestra as the MyFaces project is already confusing at
first to users due to the number of top level projects.
Also, what is up with the name? It doesn't seem to relate to what it does.
Also has
requirements come up.
-Andrew
On Fri, Apr 18, 2008 at 12:10 PM, Andy Schwartz
[EMAIL PROTECTED] wrote:
On Thu, Apr 17, 2008 at 9:21 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I'll be happy either way, but I think I now bend to the below
explanation of 5 == 5.0 from Jeanne's reasoning
FWIW, I
Perhaps matching the full agent string is a bad idea. I'd hate to have
to parse many variations of things like:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5)
Gecko/2008032620 Firefox/3.0b5
-Andrew
On Fri, Apr 18, 2008 at 12:46 PM, Andrew Robinson
[EMAIL PROTECTED] wrote
:
a.) 0b5 would become 0
b.) b5 would become which we'd treat as 0
Regards,
Matt
On Fri, Apr 18, 2008 at 12:55 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Perhaps matching the full agent string is a bad idea. I'd hate to have
to parse many variations of things like
Sorry this should have gone to dev@, not users@:
While looking at the Trinidad demo, I was thinking that it is odd that
the skins are shipped inside the demo project as opposed to jars that
can be added to user's applications.
I was thinking this layout would make more sense:
+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
I would like to have:
1) Major and Major.Minor support
2) A syntax that is already supported by CSS @ styles in at least one
browser or as close as we can come
3) Range, greater than and less than if possible
#2 I think is really important so that skinning feels familiar to CSS
developers.
If
Sorry if this has been asked before, but is anyone looking into the
Trinidad site? Many links are broken. It seems to be due to an
overabundance of trinidad-api folders in the path (2 when there should
be 1 and 1 when there should be none).
Thanks,
Andrew
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
[
https://issues.apache.org/jira/browse/TRINIDAD-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-946.
--
Resolution: Duplicate
Looks like a duplicate of TRINIDAD-673, please check
[
https://issues.apache.org/jira/browse/TRINIDAD-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-910.
--
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
[
https://issues.apache.org/jira/browse/TRINIDAD-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590165#action_12590165
]
Andrew Robinson commented on TRINIDAD-888:
--
This has been placed on hold until
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
: 5, I'd think that all minor versions of 5
would work, too.
Otherwise, I would have written max-version: 5.0.
- Jeanne
Blake Sullivan wrote, On 4/17/2008 12:58 PM PT:
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
-
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
I wish to withdraw and clarify the scope of my apology earlier on the
[EMAIL PROTECTED] mailing list regarding my overreaction and emotional
response to the replies made by Blake Sullivan on the private /
protected final methods in renderers thread. I am just as guilty or
more guilty in regards to
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
] 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
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
with enough and instead
comment on the parts that I want changed.
As Gabrielle said once (OK many times), I'll send a two page plan out for
review and you're only comments will be on these two minor points that I got
wrong.
To repeat, I'm sorry.
-- Blake Sullivan
Andrew Robinson said
In order to improve the ability to customize the rendering of Trinidad
components, an idea was proposed in the private / protected final
methods in renderers thread.
This idea is to replace existing code that has hard references to sub
renderers (directly instantiating Trinidad renderers from
The new thread has the subject:
[Trinidad] Idea to register sub-renderers in the faces configuration.
On Tue, Apr 15, 2008 at 12:39 PM, Andrew Robinson
[EMAIL PROTECTED] 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
,
--
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
,
--
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
is welcome.
On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
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
Ignore the component link, I messed that one up. The renderers are the
ones to have a look at.
On Mon, Apr 14, 2008 at 10:11 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Have you looked at my code in the branch? I think it would be good te
critique that so that there is a solid example
:
On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
Simon,
Frankly I do not understand #2, sorry. Could you explain what the
problem is in a different way? Perhaps I just have not seen something
in the current code that does something that you are referring to. I
was hoping that someone besides myself would understand what you said
better and
a top faces present.
Or am I still off base in your concern?
On Mon, Apr 14, 2008 at 10:45 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Simon,
Frankly I do not understand #2, sorry. Could you explain what the
problem is in a different way? Perhaps I just have not seen something
to and override the getter method
(getOnclick(FacesBean)) of the property we don't want to render on the
sub-part. I currently see no way to achieve that using renderers found from
the render kit.
Clearer ?
~ Simon
On Mon, Apr 14, 2008 at 12:49 PM, Andrew Robinson
[EMAIL PROTECTED] wrote
See below
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.
Gab, I
As someone who has experience in attempting to use Trinidad, I think
#3 is a requirement for short term usage and #2 as the goal.
What I mean by this is that rendereds should make an effort to expose
functionality even if it isn't thought through so that ppl can get
work done, and then have users
What I mean by this is that rendereds should make an effort to expose
functionality even if it isn't thought through
I am not a fan of this. If people want to put in the effort to think
through APIs that they expose on their renderers, then +1. But big -1
from me for exposing APIs
IMO) make the renderers do what you want them to do though
the use of attributes and better skinning?
Scott
Andrew Robinson wrote:
What I mean by this is that rendereds should make an effort to
expose
functionality even if it isn't thought through
I am not a fan
Rhetorical question--why would a company have such a policy?
Companies don't usually make sense, you must be one of those people
that think Dilbert is fiction :)
I have worked for more than one company that enforces this policy.
They hate using open source for liability reasons, and hate you
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
BTW, I want to apologize to making this thread out to be such a mess
and hope that I haven't damaged Christi's goal with improving the
library. I tend to get too passionate about code and get quite
bothered when only negative feedback is offered with no constructive
comments to suggest forward
Krishna, please post to the users list for these type of questions.
The dev list is for MyFaces developers to collaborate on working on
the code, not working with the code.
Thanks,
Andrew
On Fri, Apr 11, 2008 at 2:50 PM, Nutulapati, Krishna
[EMAIL PROTECTED] wrote:
-Original Message-
:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
The bug https://issues.apache.org/jira/browse/TOMAHAWK-858 has made me
want to bring this up for discussion of the entire team. I really
don't like the solution they are posing as it will cause backward
compatibility problems
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
+1 for:
- removing most final modifiers
- going from private to protected on most renderer methods
- and adding more customization hooks in the renderers
I also think that these should not be made backwards compatible.
Basically a use at your own risk deal. That way Trinidad developers
have the
Wrong mailing list. This is for MyFaces committers only. Please send
your mail to the shale list.
On Thu, Apr 10, 2008 at 11:23 AM, Zheng, Xiahong [EMAIL PROTECTED] wrote:
I couldn't seem to understand by looking at the clay usecase example. Can
somebody post an example of using clay to
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.
-Andrew
On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
[EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
[EMAIL PROTECTED
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
, 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
The thing is, is not what is the strive for the perfect architecture,
but what is the best way make Trinidad the easiest to use to develop
business applications with (not saying the architecture should not be
solid, just that trying to make an architecture that provides
everyones needs for every
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
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
Components: Documentation
Affects Versions: 1.2.7-core, 1.0.7-core
Reporter: Andrew Robinson
Priority: Minor
RequestContext.Accessibility as shown here:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/context
[
https://issues.apache.org/jira/browse/TRINIDAD-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1045.
---
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
When doing the panelBorderLayout enhancement, I had my first real
opportunity to work on those xss files. I can't say as I enjoyed it
that much. Is there any reason they exist, or is it simply that no one
has bothered converting them over to CSS?
If the latter is the case I could probably find
Since this is currently supported in Seam and Orchestra is a Seam
spin-off/clone, perhaps this should be incorporated into Orchestra
instead of yet another project.
On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
On Thu, Apr 3, 2008 at 10:11 PM, Gerhard
A renderer using LibraryScriptlet is getting the URL:
/trinidad-demo/adf/jsLibs/DebugApacheChart1_2_8.js
instead of:
/trinidad-demo/adf/jsLibsDebug/ApacheChart1_2_8.js
The former is what is added to the page. The latter is what is being
generated by the build. As a result, any component using
loaders find it correctly?
Thanks,
Andrew
On Fri, Apr 4, 2008 at 5:07 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
A renderer using LibraryScriptlet is getting the URL:
/trinidad-demo/adf/jsLibs/DebugApacheChart1_2_8.js
instead of:
/trinidad-demo/adf/jsLibsDebug/ApacheChart1_2_8.js
[
https://issues.apache.org/jira/browse/TRINIDAD-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1032.
---
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
Sorry to be a grouch, but I am starting to wonder if people ever test
Tobago builds before checking in code. It is a continuous source of
spam by having continuum failure and success messages at least a few
days every week. Is there anything that can be done to stop this? I
suppose I could create
I found some more (Trinidad and Tobago).
Reason (as mostly) = continuum).
Okay, thanks for looking into it. Maybe I should create a new filter
for these guys.
[
https://issues.apache.org/jira/browse/TRINIDAD-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584301#action_12584301
]
Andrew Robinson commented on TRINIDAD-1032:
---
New proposal, use
They both look nice to me, whichever is fine
-Andrew
On Mon, Mar 31, 2008 at 10:28 AM, Simon Lessard
[EMAIL PROTECTED] wrote:
Top one as well.
On Mon, Mar 31, 2008 at 11:51 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
On Mon, Mar 31, 2008 at 5:37 PM, Matt Cooper [EMAIL
Affects Versions: 1.2.7-core, 1.0.7-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Add a new component, to the trinidad-sandbox first, that is similar to the
panelBorderLayout. Unlike this component the panelStretchLayout would be
rendered using DIV instead
I would not recommend forceSpan as an attribute as the use of a span
is renderer specific, not component specific. The component should not
care how the renderer works
On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl [EMAIL PROTECTED] wrote:
Hi,
I like the idea of making that the default
The bug https://issues.apache.org/jira/browse/TOMAHAWK-858 has made me
want to bring this up for discussion of the entire team. I really
don't like the solution they are posing as it will cause backward
compatibility problems and is not a full solution. This problem is not
unique to the Tomahawk
[
https://issues.apache.org/jira/browse/TOMAHAWK-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581605#action_12581605
]
Andrew Robinson commented on TOMAHAWK-858:
--
I started a discussion on this bug
[
https://issues.apache.org/jira/browse/TRINIDAD-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581675#action_12581675
]
Andrew Robinson commented on TRINIDAD-1026:
---
I don't think anything can
[
https://issues.apache.org/jira/browse/TRINIDAD-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581675#action_12581675
]
arobinson74 edited comment on TRINIDAD-1026 at 3/24/08 2:23 PM:
Andy,
I will pause development, and write up a WIKI. The big problem with tab
indexes is tables or extra components that people don't want to tab to
(skipping over an advertisement link for example). Tables tab left to right,
sometimes people want newspaper style tabs - top to bottom then left to
for now.
-Andrew
On Sat, Mar 22, 2008 at 9:51 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Andy,
I will pause development, and write up a WIKI. The big problem with tab
indexes is tables or extra components that people don't want to tab to
(skipping over an advertisement link for example
[
https://issues.apache.org/jira/browse/TRINIDAD-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1018.
---
Resolution: Fixed
Fix Version/s: 1.2.8-core
Assignee: Andrew
We can create a better home for it during the implementation for
TRINIDAD-980, so I would think that wherever you want to place it in
the current demo would probably be okay.
-Andrew
On Thu, Mar 20, 2008 at 4:52 PM, Gabrielle Crawford
[EMAIL PROTECTED] wrote:
Hi,
I wanted to add a
I like it. Yeah, not as good as your mock-up, but It still like it
-Andrew
On Wed, Mar 19, 2008 at 12:35 PM, Catalin Kormos
[EMAIL PROTECTED] wrote:
I would like to ask for your opinion before starting to commit the new
MyFaces Maven skin (based on the designs Adonis provided). Please have a
Issue Type: Bug
Components: Documentation
Affects Versions: 1.2.7-core, 1.0.7-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Trivial
tr:iterator does not document the default value for the rows attribute
The default is 25
[
https://issues.apache.org/jira/browse/TRINIDAD-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1016.
---
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
[
https://issues.apache.org/jira/browse/TRINIDAD-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580529#action_12580529
]
Andrew Robinson commented on TRINIDAD-1016:
---
Also added it to 1.2.7.1
For trinidad:
https://issues.apache.org/jira/browse/TRINIDAD-979
https://issues.apache.org/jira/browse/TRINIDAD-980
On Wed, Mar 19, 2008 at 3:08 PM, Cagatay Civici
[EMAIL PROTECTED] wrote:
We definitely need the same for library suite demos for trinidad and
tomahawk.
Compared to other libs'
need help with the new skin and demos for Trinidad based
on the new look of the website, i'm sure Adonis can give you a hand.
regards,
Catalin
On Thu, Mar 20, 2008 at 12:02 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
For trinidad:
https://issues.apache.org/jira/browse/TRINIDAD-979
One major drawback to the javadoc annotation approach has been left
out and that is attribute reuse. The maven-faces-plugin allows you to
import XML fragments using XPath. So in Trinidad, onclick,
onmouseover, onmouseout, etc. you can import one XML file and not have
to re-define all these. But
On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi Andrew,
Andrew Robinson schrieb:
One major drawback to the javadoc annotation approach has been left
out and that is attribute reuse. The maven-faces-plugin allows you to
import XML fragments using XPath
On Tue, Mar 18, 2008 at 11:28 AM, Gabrielle Crawford
[EMAIL PROTECTED] wrote:
I know this has been considered many times in the past, but not
implemented due to complexity.
What complexity are you referring to? Could you please provide
concrete examples? Thanks.
When you know the details of
On Tue, Mar 18, 2008 at 12:47 PM, Gabrielle Crawford
[EMAIL PROTECTED] wrote:
Unfortunately I can't remember the details. Blake Sullivan and Andy
Schwartz aren't around this week, but they may know more.
Not a problem, I don't see myself getting too much done this week with
Easter coming up.
[
https://issues.apache.org/jira/browse/TRINIDAD-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1011.
---
Resolution: Fixed
Fix Version/s: 1.2.7-plugins
Committed to 1.2.6.1
Andrew Robinson wrote:
I was working on the feature to add tab index to components tonight
and after getting it to work with the color palette (chooseColor), I
don't think that it is very useful. There are just too many links to
tab through. Perhaps I can just enable
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Is this supposed to be a solution to the code replacement? I don't
recall any vote to achieve a resolution on how to go about the code
generation. From what this looks like, it looks worse than the current
trinidad plugin. Embedding data in
entering the color with keyboard is a good point, so I agree not a
showstopper,
For the spinbox I agree it's a much less annoying case than the
chooseColor, but still, I agree with Matthias that 1 tab stop would be
preferable to 3.
Actually, with chooseColor there are usually 49 tab
I'm confused though, are you just controlling the number of tab stops in
the implementation? Meaning you're not trying to add a public api for
the user to control tab stops on the page, are you?
The bug is to add a tabIndex attribute onto certain components so that
users have control over
: Plugins
Affects Versions: 1.2.7-core, 1.0.7-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Looking to add 2 new properties to be supported for the maven faces plug-in
that will be leveraged in JDev:
mfp:grouping-element - allow the user to specify when
501 - 600 of 924 matches
Mail list logo
