You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Cristi Toth <cr...@gmail.com> on 2007/09/27 17:09:25 UTC

[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] Skinning the tree

Posted by Cristi Toth <cr...@gmail.com>.
On 9/27/07, Jeanne Waldman <je...@oracle.com> 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.png<http://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

Re: [Trinidad] Skinning the tree

Posted by Adam Winer <aw...@gmail.com>.
I agree with Jeanne's suggestions - and also with Martin!
These will be great (and long overdue) improvements.

Cheers,
Adam

On 9/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> Perfect.
>
> With these additions and some more detailed skinning of the table
> paging and sorting, we might get rid of the +/- statement about
> "design" for Trinidad at http://www.jsfmatrix.net.
>
> regards,
>
> Martin
>
> On 9/27/07, Jeanne Waldman <je...@oracle.com> 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}
> >
> >
> >  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.
> >
> >
> >  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.
> >
> >
> >  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.png
> >
> >  Is this welcomed by you guys?
> >  I like it.
> >
> >
> >  regards,
> >  --
> >  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
>

Re: [Trinidad] Skinning the tree

Posted by Martin Marinschek <ma...@gmail.com>.
Perfect.

With these additions and some more detailed skinning of the table
paging and sorting, we might get rid of the +/- statement about
"design" for Trinidad at http://www.jsfmatrix.net.

regards,

Martin

On 9/27/07, Jeanne Waldman <je...@oracle.com> 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}
>
>
>  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.
>
>
>  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.
>
>
>  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.png
>
>  Is this welcomed by you guys?
>  I like it.
>
>
>  regards,
>  --
>  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

Re: [Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1

Posted by Matthias Wessendorf <ma...@apache.org>.
>  Yeah, I was wondering what our policy is for backward compatibility between
> ValueExpression and ValueBinding.
>  I see we do it in some places (e.g., FacesBean) but not others (e.g.,
> DateTimeRangeValidator).

Not sure what you mean, but I see a set/get ValueExpression and
ValueBinding on the DateTimeRangeValidator, for instance ([1])


-Matthias

[1] http://tinyurl.com/2xsr26


>
>
>  -M
>
>
>
>  Thanks,
> Jeanne
>
>
>
>
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org

Re: [Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1

Posted by Adam Winer <aw...@gmail.com>.
For brand new APIs, I'm very tempted not to add "backwards compatibility"
to the 1.2 branch.  Dunno, could go either way on this one.

-- Adam


On 9/27/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>
> Matthias Wessendorf wrote:
> Hi,


> My understanding is that Trinidad trunk cannot use ValueExpression.
Is this
> true?

> yes, the ValueExpression comes from the unified el, which is part of JSP
> 2.1


> If so, is it ok to have an API that takes ValueBinding in trunk
> and
ValueExpression in 1.2*branch?
In other words, does the 1.2* branch of
> Trinidad have to keep backward
compatibility, thus I would have a deprecated
> constructor that takes
ValueBinding and another constructor that takes
> ValueExpression.

> I think doing the two constructors, where one takes VBinding and
> is
deprecated is OK.
JSF API itself also keeps the "old" methods for
> backward compatibility
and adds new APIs that
work w/ the javax.el clazzes

> Yeah, I was wondering what our policy is for backward compatibility between
> ValueExpression and ValueBinding.
> I see we do it in some places (e.g., FacesBean) but not others (e.g.,
> DateTimeRangeValidator).
>
> -M


> Thanks,
Jeanne



>

>

Re: [Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1

Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,

> My understanding is that Trinidad trunk cannot use ValueExpression.
> Is this true?

yes, the ValueExpression comes from the unified el, which is part of JSP 2.1

>
> If so, is it ok to have an API that takes ValueBinding in trunk and
> ValueExpression in 1.2*branch?
> In other words, does the 1.2* branch of Trinidad have to keep backward
> compatibility, thus I would have a deprecated constructor that takes
> ValueBinding and another constructor that takes ValueExpression.

I think doing the two constructors, where one takes VBinding and is
deprecated is OK.
JSF API itself also keeps the "old" methods for backward compatibility
and adds new APIs that
work w/ the javax.el clazzes

-M

>
>
> Thanks,
> Jeanne
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org

[Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1

Posted by Jeanne Waldman <je...@oracle.com>.
Hi,

I have a question about ValueExpression and ValueBinding.

I have a new API to handle the translation-source feature for skins. The 
SkinAddition has a new constructor that takes
a ValueExpression in the 1.2* Trinidad branch and a ValueBinding in 
Trinidad trunk.

My understanding is that Trinidad trunk cannot use ValueExpression.
Is this true?

If so, is it ok to have an API that takes ValueBinding in trunk and 
ValueExpression in 1.2*branch?
In other words, does the 1.2* branch of Trinidad have to keep backward 
compatibility, thus I would have a deprecated constructor that takes 
ValueBinding and another constructor that takes ValueExpression.


Thanks,
Jeanne