Re: Next steps? (was Re: Is trinidad ready for graduation ?)
Simon, I like your arguments and after reading this thread, I like the idea of a subproject better than a TLP too. I wanted to comment so ya'll will know there are more people reading the thread and forming an opinion than have been commenting thus far. :) - Jeanne Simon Lessard wrote: Personally I don't think a TLP would be a good idea just yet since JSF is still relatively new compared to some older well known frameworks. I think it's easier for new users to find all they need from one entry point and MyFaces seems the right place for that, at least for now. Also, being a subproject will probably improve the users' confidence in library compatibility as well as encourage that compatibility to be kept/improved by developers. It may just be a feeling, but it seems to me that making Trinidad TLP right away would make it look a bit like a loner, especially since Tobago and Tomahawk are MyFaces sub projects. If JSF component sets should be TLP(s), then I think it should be done all at the same time, and this cannot be achieved until we harmonize Tomahawk, Trinidad and Tobago imho. My 2¢, ~ Simon On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: That was also a point of Noel, when proposing the RCF donation thing. He was asking, why not having a JSF components project. Perhaps that might be an interesting option, not sure yet; but when RCF arrives somewhen.. there would be another component set. Perhaps we should move the discussion for a split to the MyFaces DEV list, that the MyFaces PMC is also able to comment. The components project could have a similar fashion like Jakarta. But since this isn't yet the case, I'd agree that a subproject is the best, for now. -Matthias On 4/11/07, Adam Winer [EMAIL PROTECTED] wrote: If there was an idea to split MyFaces into an implementation half and a component set half, each as separate TLPs, then I'd see your point - but as it is, MyFaces the TLP is both an implementation and (currently) 2 component sets. -- Adam On 4/10/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry for the one in all reply.. Ok, let's switch perspective's here. MyFaces (the codebase) is a JSF implementation. Tomahawk and Trinidad are JSF component sets. I am not comparing the possible overlap of the component sets, I am focussing on the possible lack of overlap in community of the JSF implementation and the component sets. Different goals, different users and different developers (although the last is not yet the case, it is most likely someone interested in components is not interested in coding on the JSF implementation). Just playing bad cop here though, to hopefully prevent this situation (if you are aware of these signs you can watch out for it) Not going to vote -1 on a move to MyFaces. Mvgr, Martin -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [XRTS] overhaul of the NumberConverter messages (their details)
That sounds great to me.
- Jeanne
Martin Marinschek wrote:
Well, that's certainly a good idea!
regards,
Martin
On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEllo,
currently we have something like:
The value {1} is not a valid currency value.
or
The value {1} is not a valid percentage value.
as the detail message for the FacesMessage. The DateTimeConverter is
much nicer to the user. It is providing an example, using the
right format/pattern.
I'd like to add something like that to the NumberConverter as well.
Thanks,
MAtthias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: return an Iterator vs a List
This is the case. It is really to use the fun new for syntax. At least
for now.
- Jeanne
Simon Lessard wrote:
In that specific case Iterable would be nice yeah.
On 4/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
+1
On 4/5/07, Adam Winer [EMAIL PROTECTED] wrote:()
If the only reason is to enable the fun new for syntax,
then we should change the type from Iterator to Iterable,
instead of List. List is a much larger contract.
-- Adam
On 3/28/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I'm in the Skinning StyleNode code and I see that the 'get' methods
return Iterators
from the good ol' days.
It seems to me that it is better if they just return Lists so the
code
that iterates over
the values is cleaner using 5.0's for(String foo : yyy) construct.
Does anyone see why I wouldn't want these to return List instead of
Iterator?
Here's a code snippet. Thanks, Jeanne
--
public IteratorIncludePropertyNode getIncludedProperties()
{
if(_includedProperties == null)
{
ListIncludePropertyNode list = Collections.emptyList();
return list.iterator();
}
else
return (Arrays.asList(_includedProperties)).iterator();
}
/**
* Gets the properties specified by this node's parent that should
be
* ignored. This method will return an empty iterator if
* [EMAIL PROTECTED] #isInhibitingAll()} returns codetrue/code
*
* @return an iterator over the properties that should be ignored,
an
* empty iterator if all properties should be.
*/
public IteratorString getInhibitedProperties()
{
if(_inhibitedProperties == null)
{
ListString list = Collections.emptyList();
return list.iterator();
}
else
{
return _inhibitedProperties.iterator();
}
}
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
[API] new api on Skin
I'm close to checking in the code regarding adding the Skin's styleSheetDocument's id to the generated css file instead of the version so it will changed when the skin's styles change.. I created a JIRA issue to track it. http://issues.apache.org/jira/browse/ADFFACES-439 ALSO: I would like to propose an API on the Skin class to get the Skin's StyleSheetDocument's id. This is so a portal can tell us not to render our stylesheet if they have a matching one. They can use this api to get their stylesheet document id and send it to us, along with a suppressStylesheet flag, and we can suppress the stylesheet if they match, otherwise, we'll default to the portlet skin. /** * Returns the id of the Skin's stylesheet document. This is the StyleSheetDocument's * id. */ public String getStyleSheetDocumentId(RenderingContext arc); Thanks, Jeanne Jeanne Waldman wrote: Hello, I'm proposing putting a hashcode value in the generated css file instead of a version string. Let me explain why: Now your generated css file will be something like this purple-desktop-incubator-1_2-07-mar-SNAPSHOT-en-ltr-ie-6.css where the version is 1_2-07-mar-SNAPSHOT The version # was in the css file name originally so that when a new version was released the css file name would change and thus the user will get the new css file instead of the old one that is cached in the browser. A person that creates a skin might update his skin more often than Trinidad releases and so he'll want the generated css filename to change to match his release, not Trinidad's. One way to work around the problem is to add the version to the skin file and use that in the generated filename. But that is one more file that has to get updated when someone changes the skin and/or releases a new release, so I don't like that idea. I've also discussed with some coworkers using a timestamp, but that got nixed because of the complexities that might occur in load-balanced environments. I think a better way is to create a hashcode of the Skin's StyleSheetDocument and write this in the file. So far people seem to like this idea, and I want to know what you think. Creating a hashcode on StyleSheetDocument also solves another problem I must solve for the portal project I'm working on. They want to tell me to use a particular skin and suppress my stylesheet so that their stylesheet can be used instead - this is for performance reasons. I can do that ok, but only if the skin's StyleSheetDocument's hashcode matches, otherwise the portlet may very well not work with the outer page's (portal's) stylesheet if they don't match exactly. So I need the portal to tell me their skin's StyleSheetDocument's 'id/hashcode' and I will compare it to the portlet's and if they are not the same I will render the portlet skin instead of the skin they requested. Anyway, let me know what you think about adding the hashcode to the filename or if you have any questions about this proposal. Also, for the portal part of the problem, I'll need to add an api to the Skin class to getStyleSheetDocumentId or something like that. Thanks, Jeanne
add hashcode in the generated css file instead of version?
Hello, I'm proposing putting a hashcode value in the generated css file instead of a version string. Let me explain why: Now your generated css file will be something like this purple-desktop-incubator-1_2-07-mar-SNAPSHOT-en-ltr-ie-6.css where the version is 1_2-07-mar-SNAPSHOT The version # was in the css file name originally so that when a new version was released the css file name would change and thus the user will get the new css file instead of the old one that is cached in the browser. A person that creates a skin might update his skin more often than Trinidad releases and so he'll want the generated css filename to change to match his release, not Trinidad's. One way to work around the problem is to add the version to the skin file and use that in the generated filename. But that is one more file that has to get updated when someone changes the skin and/or releases a new release, so I don't like that idea. I've also discussed with some coworkers using a timestamp, but that got nixed because of the complexities that might occur in load-balanced environments. I think a better way is to create a hashcode of the Skin's StyleSheetDocument and write this in the file. So far people seem to like this idea, and I want to know what you think. Creating a hashcode on StyleSheetDocument also solves another problem I must solve for the portal project I'm working on. They want to tell me to use a particular skin and suppress my stylesheet so that their stylesheet can be used instead - this is for performance reasons. I can do that ok, but only if the skin's StyleSheetDocument's hashcode matches, otherwise the portlet may very well not work with the outer page's (portal's) stylesheet if they don't match exactly. So I need the portal to tell me their skin's StyleSheetDocument's 'id/hashcode' and I will compare it to the portlet's and if they are not the same I will render the portlet skin instead of the skin they requested. Anyway, let me know what you think about adding the hashcode to the filename or if you have any questions about this proposal. Also, for the portal part of the problem, I'll need to add an api to the Skin class to getStyleSheetDocumentId or something like that. Thanks, Jeanne
kill CompoundPropertyNode code in skinning
Hi there, I want to delete the CompoundPropertyNode code from the skinning code. Currently you could use it if you wanted, but only from the XSS file. We aren't using it from our XSS files. This is some old doc for it: The following example shows a border property defined using theproperty element: | | property name=border2px dashed #336699/property Since the border property value is itself a list of values, it can also be defined using thecompoundProperty element: | | compoundProperty name=border value2px/value valuedashed/value value#336699/value /compoundProperty The corresponding CSS that is generated for this compound property is: | | border:2px dashed #336699 Compound properties are more used when used in conjunction with theincludeValue element. For example, includeValue can be used in this example to pick up the border's color from some other shared style: | | compoundProperty name=border value2px/value valuedashed/value includeValue name=DarkForeground propertyName=color/ /compoundProperty Using theincludeValue element in this way can simplify customization. In this case, changes to the DarkForeground style are automatically propagated to the color used by this border property. I wanted to give a heads up before I delete the code that refers to this. Let me know how you feel about deleting the code. Thanks, Jeanne
Re: kill CompoundPropertyNode code in skinning
No, it's not documented at all in Trinidad, or at least not that I found anywhere. The only documentation I found is for JDeveloper 10.1.2 http://www.oracle.com/webapps/online-help/jdeveloper/10.1.2/state/content/navId.4/navSetId._/vtTopicFile.uixhelp%7Cuixref%7Cstyle%7CcompoundProperty~html/ We do have a feature that is similar to compoundProperty called includeProperty that isn't available yet in CSS but is in XSS. I hope we can move this forward into CSS sometime. Here is an example from our base-desktop.xss file: !-- AFVeryDarkForeground is the darkest foreground color in the core (green) color ramp -- style name=AFVeryDarkForeground includeProperty name=AFVeryDarkBackground propertyName=background-color localPropertyName=color/ /style It's saying, Set the 'color' to whatever AFVeryDarkBackground's 'background-color' is - Jeanne Matt Cooper wrote: I too prefer CSS over XSS. Jeanne: is this documented at all in any Trinidad documentation? If not then +1 (non-binding) from me. If it is in Trinidad documentation then I'd wait to see if anyone else still wants it. On 3/27/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmmm, I'm +1. It's not a bad feature, but I'm not too fond of XSS. On 3/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I want to delete the CompoundPropertyNode code from the skinning code. Currently you could use it if you wanted, but only from the XSS file. We aren't using it from our XSS files. This is some old doc for it: The following example shows a border property defined using theproperty element: | | property name=border2px dashed #336699/property Since the border property value is itself a list of values, it can also be defined using thecompoundProperty element: | | compoundProperty name=border value2px/value valuedashed/value value#336699/value /compoundProperty The corresponding CSS that is generated for this compound property is: | | border:2px dashed #336699 Compound properties are more used when used in conjunction with theincludeValue element. For example, includeValue can be used in this example to pick up the border's color from some other shared style: | | compoundProperty name=border value2px/value valuedashed/value includeValue name=DarkForeground propertyName=color/ /compoundProperty Using theincludeValue element in this way can simplify customization. In this case, changes to the DarkForeground style are automatically propagated to the color used by this border property. I wanted to give a heads up before I delete the code that refers to this. Let me know how you feel about deleting the code. Thanks, Jeanne
Re: Getting rid of an ugly assert usage
That's pretty tricky... and confusing!
I'm fine with getting rid of it.
- Jeanne
Simon Lessard wrote:
Well yeah, it's very hard to read
boolean assertEnabled = false; // Ok we got a variable with value set to
false
assert assertEnabled = true; // This is an assignment, not a
comparison, so
if assert is enabled, the line will be executed and assertEnabled
value will
now be true. Furthermore, since the value of an assignment is the
assigned
value, the assert is really assert true; and thus never fail. If
assert is
not enabled, assertEnabled keeps its value to false.
if (assertEnabled)
{
// This code will execute only if assert is enabled
}
It's really really ugly imho.
On 3/15/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
You mean this part?
boolean assertEnabled = false;
assert assertEnabled = true;
...
if (assertEnabled)
It doesn't make sense to me.
- Jeanne
Adam Winer wrote:
Yeah, that abuse of assert always bugged me.
-- Adam
On 3/15/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello all,
I would like to get rid of the following code snippet from
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.table.RowData
and
make that usage forbidden in our coding conventions wiki, as it's
really a
poor man's #ifdef __DEBUG and goes against the idea of assert not
having
any
performance overhaul at runtime.
boolean assertEnabled = false;
assert assertEnabled = true;
...
if (assertEnabled)
{
// make sure prev operation was get:
assert (_currentRowSpanState == 2);
_currentRowSpanState = 0; // indicate that we have reset the
rowspan
}
Any objection?
~ Simon
[BUG] recent trouble running Trinidad
Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
No, I'm not running in a Portal. I'll look into it some. If anyone else sees this issue, let me know. Jeanne Scott O'Bryan wrote: The reason I ask is that I was getting a similar error (to the StateFieldMarker markup) when using the 1.2 branch, in the Portal Proof of Concept environment, with some of my extension involved. But I tracked this down to be an issue with the bridge I was using. I did NOT see this behavior in 1.1 or when running outside of a Portal environment in 1.2. As for the RenderingContext, I didn't mess with any of this code as part of either of these patches. So it doesn't seem like the issues are related to me. Scott Scott O'Bryan wrote: Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
I did a clean build and it works fine now. Something must have gotten corrupted. I'll apply your 379 to trunk. - Jeanne Scott O'Bryan wrote: Jeanne, I was looking at the trunk and it appears that ADFFACES-379 was not applied to trunk and ADFFACES-374 is 1.2 only. So no, this issue is not related being that none of the patched code is actually in the trunk. :) After you figure out the issue, can you look at applying ADFFACES-379 to trunk? Thanks, Scott Jeanne Waldman wrote: No, I'm not running in a Portal. I'll look into it some. If anyone else sees this issue, let me know. Jeanne Scott O'Bryan wrote: The reason I ask is that I was getting a similar error (to the StateFieldMarker markup) when using the 1.2 branch, in the Portal Proof of Concept environment, with some of my extension involved. But I tracked this down to be an issue with the bridge I was using. I did NOT see this behavior in 1.1 or when running outside of a Portal environment in 1.2. As for the RenderingContext, I didn't mess with any of this code as part of either of these patches. So it doesn't seem like the issues are related to me. Scott Scott O'Bryan wrote: Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: Patches
Scott, I'll do my best to review your patches and check them into trunk and the JSF 1.2 branch. It would be great if someone else can give their feedback, since I'm not that familiar with what you are doing here.. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: Patches
Oh, I see Adam already did this. Thanks Adam. Jeanne Waldman wrote: Scott, I'll do my best to review your patches and check them into trunk and the JSF 1.2 branch. It would be great if someone else can give their feedback, since I'm not that familiar with what you are doing here.. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
[Skinning] FileSystemStyleCache code - ok to delete?
I'm trying to figure out what's going on in FileSystemStyleCache
regarding the caching code.
I noticed that this code is not called by anyone. Does anyone object to
my deleting it? Or is there
some use for it so I should keep it around.
/**
* Returns a shared ImageProvider instance for the specified
* XSS document and target cache directory.
*
* @param source The path of the source XSS document. The
* specified file must be a valid XSS document. If the specified
* file does not exists, an IllegalArgumentException is thrown.
* @param target The path of the target directory. Generated
* CSS files are stored in this directory. If the directory
* does not exist and can not be created, an IllegalArgumentException
* is thrown.
*/
public static StyleProvider getSharedCache(
String source,
String target
)
{
// Make sure we have some source/target.
if (source == null)
throw new IllegalArgumentException(No source specified.);
if (target == null)
throw new IllegalArgumentException(No target specified.);
// First, get the key to use to look up the cache
String key = _getSharedCacheKey(source, target);
// See if we've got a shared cache
StyleProvider cache = _sSharedCaches.get(key);
// If we didn't find a shared cache, create a new cache
// and cache it in the shared cache cache. :-)
if (cache == null)
{
// Create the new cache
cache = new FileSystemStyleCache(source, target);
// Before we save the new cache, make sure another thread hasn't
// already cached a different instance. Synchronize to lock up
// _sSharedCaches.
synchronized (_sSharedCaches)
{
StyleProvider tmp = _sSharedCaches.get(key);
if (tmp != null)
{
// Stick with tmp
cache = tmp;
}
else
{
_sSharedCaches.put(key, cache);
}
}
}
return cache;
}
Re: [Skinning] FileSystemStyleCache code - ok to delete?
thanks. I'll kill it right now.
Adam Winer wrote:
Die die die. :)
Unused code should almost always go. It can always
be revived from source control, and if it's unused, the
odds that it works steadily decreases as time goes on.
-- Adam
On 2/12/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I'm trying to figure out what's going on in FileSystemStyleCache
regarding the caching code.
I noticed that this code is not called by anyone. Does anyone object to
my deleting it? Or is there
some use for it so I should keep it around.
/**
* Returns a shared ImageProvider instance for the specified
* XSS document and target cache directory.
*
* @param source The path of the source XSS document. The
* specified file must be a valid XSS document. If the specified
* file does not exists, an IllegalArgumentException is thrown.
* @param target The path of the target directory. Generated
* CSS files are stored in this directory. If the directory
* does not exist and can not be created, an
IllegalArgumentException
* is thrown.
*/
public static StyleProvider getSharedCache(
String source,
String target
)
{
// Make sure we have some source/target.
if (source == null)
throw new IllegalArgumentException(No source specified.);
if (target == null)
throw new IllegalArgumentException(No target specified.);
// First, get the key to use to look up the cache
String key = _getSharedCacheKey(source, target);
// See if we've got a shared cache
StyleProvider cache = _sSharedCaches.get(key);
// If we didn't find a shared cache, create a new cache
// and cache it in the shared cache cache. :-)
if (cache == null)
{
// Create the new cache
cache = new FileSystemStyleCache(source, target);
// Before we save the new cache, make sure another thread hasn't
// already cached a different instance. Synchronize to lock up
// _sSharedCaches.
synchronized (_sSharedCaches)
{
StyleProvider tmp = _sSharedCaches.get(key);
if (tmp != null)
{
// Stick with tmp
cache = tmp;
}
else
{
_sSharedCaches.put(key, cache);
}
}
}
return cache;
}
Re: [Skinning] CSS selector limit hit in IE
Hi there, I've changed my mind and instead added this to FileSystemStyleCache. It is cleaner. I didn't do this in the first place because I needed the RenderingContext, and I didn't think I had it. But then I noticed that I have it with the getCurrentInstance method. Map skinsStyleClassMap = context.getSkin().getStyleClassMap( RenderingContext.getCurrentInstance()); String disableContentCompression = FacesContext.getCurrentInstance().getExternalContext(). getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION); boolean compressStyles = (skinsStyleClassMap == shortStyleClassMap) !true.equals(disableContentCompression); Jeanne Waldman wrote: This is what I've done: Added a getSkin() on the StyleContext object which I think is a fine thing to do, since the StyleContext gives us information we need to be able to output the stylesheet. Then I can do this to see if I need to output the compressed styleclasses or the uncompressed styleclasses: String disableContentCompression = FacesContext.getCurrentInstance().getExternalContext(). getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION); // we do not compress if it is a portlet skin boolean isPortletSkin = CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId()); boolean compressStyles = (!true.equals(disableContentCompression)) !isPortletSkin; Simon Lessard wrote: That works, true. On 2/1/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Simon Lessard wrote: Hello Jeanne, I thought about skinning and portlet before and I came upon pretty much the same conclusion. However in my idea it was more like a predefined skin family, like containerProvided maybe. Then renderer would always uses uncompressed selectors and would leave style/ tag generation to the container. Then again the container would need a way to produce the CSS, but I was not yet to that point. I guess a flag in the skin definition works as well, but it seems a bit strange to have a skin specific for a portlet environment, I would have preferred to be able to use any skin. Like we have desktop skins, pda skins, we can now also have portlet skins. This way we don't change the skin-family. We we have a SimpleDesktop skin, a SimplePda skin, we now also have a SimplePortlet skin. Regards, ~ Simon On 2/1/07, Jeanne Waldman [EMAIL PROTECTED] wrote: I just thought of a reason why I can't simply compress or uncompress based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new portal skin we've introduced in the portal branch. We don't compress our styleclasses when using the portal skin. The way the skinning works now in the portal branch is: 1. It assumes we write out both full and compressed styleclasses in our generated css file. 2. The Skin has a getStyleClassMap method. For all skins except portal skins, it returns our styleclass compression map if we aren't disabling content compression, else null; for portal skins it returns a Trinidad styleclass to portal styleclass map. I can see upon writing out the css file I look to see if it is a portal, etc. Or what do people think about a flag in the Skin that tells me if the StyleClassMap is the compression map that we use to generate the css? Or maybe in our css generation code we can look at the skin's styleclass map and glean information from it? Maybe see if it is the same compression map that we are using to generate the css file and if so, then it's ok to just write out compression, and if not, then we don't??? I'll see what I can do, but I'll want a code review to make sure it is the best solution. Thanks, Jeanne Matt Cooper wrote: That sounds like a reasonable first step to me since that would reduce the size the most. Thanks On 1/31/07, Simon Lessard [EMAIL PROTECTED] wrote: I agree, only one version compressed or uncompressed should be enough for a while. On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Simon Lessard wrote: On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote: On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote: As Adam suggest, we could do some runtime evaluation during CSS generation and have many selector uses the same compressed selector, this would be a 50% gain or so. I can do this, too, if we feel we have to. The logic flow will have to change, of course. Right now we build the shortened style class map, then we generate the css file. I'd have to either change the shortened style class map as I merge styles, or create it a bit later. It's no big deal, just more overhead when we create the file. Maybe this goes without saying but we have to be careful when doing this so
Re: [Skinning] CSS selector limit hit in IE
I just thought of a reason why I can't simply compress or uncompress
based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
portal skin we've introduced in the portal branch. We don't compress our
styleclasses when using the portal skin.
The way the skinning works now in the portal branch is:
1. It assumes we write out both full and compressed styleclasses in our
generated css file.
2. The Skin has a getStyleClassMap method. For all skins except portal
skins, it returns our styleclass compression map if we aren't disabling
content compression, else null; for portal skins it returns a Trinidad
styleclass to portal styleclass map.
I can see upon writing out the css file I look to see if it is a portal,
etc.
Or what do people think about a flag in the Skin that tells me if the
StyleClassMap is the compression map that we use to generate the css?
Or maybe in our css generation code we can look at the skin's styleclass
map and glean information from it? Maybe see if it is the same
compression map that we are using to generate the css file and if so,
then it's ok to just write out compression, and if not, then we don't???
I'll see what I can do, but I'll want a code review to make sure it is
the best solution.
Thanks,
Jeanne
Matt Cooper wrote:
That sounds like a reasonable first step to me since that would reduce
the
size the most.
Thanks
On 1/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
I agree, only one version compressed or uncompressed should be enough
for
a
while.
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Simon Lessard wrote:
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
As Adam suggest, we could do some runtime evaluation during CSS
generation
and have many selector uses the same compressed selector, this
would
be
a
50% gain or so.
I can do this, too, if we feel we have to. The logic flow will
have
to
change, of course.
Right now we build the shortened style class map, then we
generate
the
css file.
I'd have to either change the shortened style class map as I
merge
styles, or create it a bit later.
It's no big deal, just more overhead when we create the file.
Maybe this goes without saying but we have to be careful when doing
this
so
that we only use the same selector when the containment definitions
are
also
the same.
If we just have:
.Foo,
.Bar {
color: red;
}
then this could be compressed down to:
.x1 {
color: red;
}
But if we have:
.Foo,
.Bar {
color: red;
}
.Foo .Joe {
color: green;
}
.Bar .Joe {
color: blue;
}
then we cannot use the same compressed name for Foo and Bar, we'd
compress
to:
.x1,
.x2 {
color: red;
}
.x1 .x3 {
color: green;
}
.x2 .x3 {
color: blue;
}
If we had:
.Foo,
.Bar {
color: red;
}
.Foo .Joe,
.Bar .Joe {
color: green;
}
then we could compress down to:
.x1 {
color: red;
}
.x1 .x2 {
color: green;
}
Yeah that would require quite a lot of evaluation after parsing, if
that's
done maybe we should consider generating the CSS files at app.
startup
rather than at first request because that kind of processing would
most like
be O(n!) or O(x^n).
I was thinking if a style is used anywhere else, period, we do not
merge
that with another style. That is less processing, at least.
Personally, I think doing the only-generated-compressed-styles
solution
or (only-non-uncompressed) is enough to solve this problem for a
while.
I think this merging solution is lower priority, and more of a
nice-to-have. What does everyone else think?
If there is another reason to do this, like performance, and we
know the
impact, then that's another thing, but I'd like
to focus on this issue and the solution right now -- especially since
we've hit this limit.
- Jeanne
Re: [Skinning] CSS selector limit hit in IE
Simon Lessard wrote:
Hello Jeanne,
I thought about skinning and portlet before and I came upon pretty
much the
same conclusion. However in my idea it was more like a predefined skin
family, like containerProvided maybe. Then renderer would always uses
uncompressed selectors and would leave style/ tag generation to the
container. Then again the container would need a way to produce the
CSS, but
I was not yet to that point.
I guess a flag in the skin definition works as well, but it seems a bit
strange to have a skin specific for a portlet environment, I would have
preferred to be able to use any skin.
Like we have desktop skins,
pda skins, we can now also have portlet skins.
This way we don't change the skin-family.
We we have a SimpleDesktop skin, a SimplePda skin, we
now also have a SimplePortlet skin.
Regards,
~ Simon
On 2/1/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I just thought of a reason why I can't simply compress or uncompress
based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
portal skin we've introduced in the portal branch. We don't compress our
styleclasses when using the portal skin.
The way the skinning works now in the portal branch is:
1. It assumes we write out both full and compressed styleclasses in our
generated css file.
2. The Skin has a getStyleClassMap method. For all skins except portal
skins, it returns our styleclass compression map if we aren't disabling
content compression, else null; for portal skins it returns a Trinidad
styleclass to portal styleclass map.
I can see upon writing out the css file I look to see if it is a portal,
etc.
Or what do people think about a flag in the Skin that tells me if the
StyleClassMap is the compression map that we use to generate the css?
Or maybe in our css generation code we can look at the skin's styleclass
map and glean information from it? Maybe see if it is the same
compression map that we are using to generate the css file and if so,
then it's ok to just write out compression, and if not, then we don't???
I'll see what I can do, but I'll want a code review to make sure it is
the best solution.
Thanks,
Jeanne
Matt Cooper wrote:
That sounds like a reasonable first step to me since that would reduce
the
size the most.
Thanks
On 1/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
I agree, only one version compressed or uncompressed should be enough
for
a
while.
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Simon Lessard wrote:
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
As Adam suggest, we could do some runtime evaluation during
CSS
generation
and have many selector uses the same compressed selector,
this
would
be
a
50% gain or so.
I can do this, too, if we feel we have to. The logic flow will
have
to
change, of course.
Right now we build the shortened style class map, then we
generate
the
css file.
I'd have to either change the shortened style class map as I
merge
styles, or create it a bit later.
It's no big deal, just more overhead when we create the file.
Maybe this goes without saying but we have to be careful when
doing
this
so
that we only use the same selector when the containment
definitions
are
also
the same.
If we just have:
.Foo,
.Bar {
color: red;
}
then this could be compressed down to:
.x1 {
color: red;
}
But if we have:
.Foo,
.Bar {
color: red;
}
.Foo .Joe {
color: green;
}
.Bar .Joe {
color: blue;
}
then we cannot use the same compressed name for Foo and Bar,
we'd
compress
to:
.x1,
.x2 {
color: red;
}
.x1 .x3 {
color: green;
}
.x2 .x3 {
color: blue;
}
If we had:
.Foo,
.Bar {
color: red;
}
.Foo .Joe,
.Bar .Joe {
color: green;
}
then we could compress down to:
.x1 {
color: red;
}
.x1 .x2 {
color: green;
}
Yeah that would require quite a lot of evaluation after
parsing, if
that's
done maybe we should consider generating the CSS files at app.
startup
rather than at first request because that kind of processing
would
most like
be O(n!) or O(x^n).
I was thinking if a style is used anywhere else, period, we do not
merge
that with another style. That is less processing, at least.
Personally, I think doing the only-generated-compressed-styles
solution
or (only-non-uncompressed) is enough to solve this problem for a
while.
I think this merging solution is lower priority, and more of a
nice-to-have. What does everyone else think?
If there is another reason to do this, like performance, and we
know the
impact, then that's another thing, but I'd like
to focus on this issue and the solution right now -- especially
since
we've hit
Re: [Skinning] CSS selector limit hit in IE
This is what I've done:
Added a getSkin() on the StyleContext object which I think is a fine
thing to do, since the StyleContext
gives us information we need to be able to output the stylesheet.
Then I can do this to see if I need to output the compressed
styleclasses or the uncompressed styleclasses:
String disableContentCompression =
FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
// we do not compress if it is a portlet skin
boolean isPortletSkin =
CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());
boolean compressStyles = (!true.equals(disableContentCompression))
!isPortletSkin;
Simon Lessard wrote:
That works, true.
On 2/1/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Simon Lessard wrote:
Hello Jeanne,
I thought about skinning and portlet before and I came upon pretty
much the
same conclusion. However in my idea it was more like a predefined skin
family, like containerProvided maybe. Then renderer would always
uses
uncompressed selectors and would leave style/ tag generation to the
container. Then again the container would need a way to produce the
CSS, but
I was not yet to that point.
I guess a flag in the skin definition works as well, but it seems a
bit
strange to have a skin specific for a portlet environment, I would
have
preferred to be able to use any skin.
Like we have desktop skins,
pda skins, we can now also have portlet skins.
This way we don't change the skin-family.
We we have a SimpleDesktop skin, a SimplePda skin, we
now also have a SimplePortlet skin.
Regards,
~ Simon
On 2/1/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I just thought of a reason why I can't simply compress or uncompress
based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
portal skin we've introduced in the portal branch. We don't compress
our
styleclasses when using the portal skin.
The way the skinning works now in the portal branch is:
1. It assumes we write out both full and compressed styleclasses
in our
generated css file.
2. The Skin has a getStyleClassMap method. For all skins except
portal
skins, it returns our styleclass compression map if we aren't
disabling
content compression, else null; for portal skins it returns a
Trinidad
styleclass to portal styleclass map.
I can see upon writing out the css file I look to see if it is a
portal,
etc.
Or what do people think about a flag in the Skin that tells me if the
StyleClassMap is the compression map that we use to generate the css?
Or maybe in our css generation code we can look at the skin's
styleclass
map and glean information from it? Maybe see if it is the same
compression map that we are using to generate the css file and if so,
then it's ok to just write out compression, and if not, then we
don't???
I'll see what I can do, but I'll want a code review to make sure
it is
the best solution.
Thanks,
Jeanne
Matt Cooper wrote:
That sounds like a reasonable first step to me since that would
reduce
the
size the most.
Thanks
On 1/31/07, Simon Lessard [EMAIL PROTECTED] wrote:
I agree, only one version compressed or uncompressed should be
enough
for
a
while.
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Simon Lessard wrote:
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
As Adam suggest, we could do some runtime evaluation
during
CSS
generation
and have many selector uses the same compressed selector,
this
would
be
a
50% gain or so.
I can do this, too, if we feel we have to. The logic flow
will
have
to
change, of course.
Right now we build the shortened style class map, then we
generate
the
css file.
I'd have to either change the shortened style class map
as I
merge
styles, or create it a bit later.
It's no big deal, just more overhead when we create the
file.
Maybe this goes without saying but we have to be careful when
doing
this
so
that we only use the same selector when the containment
definitions
are
also
the same.
If we just have:
.Foo,
.Bar {
color: red;
}
then this could be compressed down to:
.x1 {
color: red;
}
But if we have:
.Foo,
.Bar {
color: red;
}
.Foo .Joe {
color: green;
}
.Bar .Joe {
color: blue;
}
then we cannot use the same compressed name for Foo and Bar,
we'd
compress
to:
.x1,
.x2 {
color: red;
}
.x1 .x3 {
color: green;
}
.x2 .x3 {
color: blue;
}
If we had:
.Foo,
.Bar {
color: red;
}
.Foo .Joe,
.Bar .Joe
Re: svn commit: r501699 - in /incubator/adffaces/trunk/trinidad: trinidad-api/pom.xml trinidad-impl/pom.xml
Folks, Matthias and I are looking at this offline. My faces-config.xml in $TRIN_HOME/trinidad-impl/target/classes/META-INF is fine. I even tested this jar and saw that my generated css file no longer has unknown-version in it. We are both on maven 2.0.4. - Jeanne Matthias Wessendorf wrote: Hey Jeanne, that fix is causing issues with the META-INF stuff in the jars (for instance an empty faces-config.xml inside the JAR, since there no one generated to $TRIN_HOME/trinidad-impl/target/classes/META-INF I did an undo for now, thx On 1/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jwaldman Date: Tue Jan 30 18:59:12 2007 New Revision: 501699 URL: http://svn.apache.org/viewvc?view=revrev=501699 Log: Added to the pom files so that the MANIFEST.MF will pick up the implementation-version String. configuration archive manifest addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /archive /configuration Modified: incubator/adffaces/trunk/trinidad/trinidad-api/pom.xml incubator/adffaces/trunk/trinidad/trinidad-impl/pom.xml Modified: incubator/adffaces/trunk/trinidad/trinidad-api/pom.xml URL: http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-api/pom.xml?view=diffrev=501699r1=501698r2=501699 == --- incubator/adffaces/trunk/trinidad/trinidad-api/pom.xml (original) +++ incubator/adffaces/trunk/trinidad/trinidad-api/pom.xml Tue Jan 30 18:59:12 2007 @@ -38,6 +38,14 @@ plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId +configuration + archive +manifest + addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries + addDefaultImplementationEntriestrue/addDefaultImplementationEntries +/manifest + /archive +/configuration executions execution goals Modified: incubator/adffaces/trunk/trinidad/trinidad-impl/pom.xml URL: http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/pom.xml?view=diffrev=501699r1=501698r2=501699 == --- incubator/adffaces/trunk/trinidad/trinidad-impl/pom.xml (original) +++ incubator/adffaces/trunk/trinidad/trinidad-impl/pom.xml Tue Jan 30 18:59:12 2007 @@ -88,6 +88,14 @@ plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId + configuration + archive + manifest + addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries + addDefaultImplementationEntriestrue/addDefaultImplementationEntries + /manifest + /archive + /configuration executions execution goals
Re: [Skinning] CSS selector limit hit in IE
Simon Lessard wrote:
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
As Adam suggest, we could do some runtime evaluation during CSS
generation
and have many selector uses the same compressed selector, this would
be
a
50% gain or so.
I can do this, too, if we feel we have to. The logic flow will have to
change, of course.
Right now we build the shortened style class map, then we generate the
css file.
I'd have to either change the shortened style class map as I merge
styles, or create it a bit later.
It's no big deal, just more overhead when we create the file.
Maybe this goes without saying but we have to be careful when doing this
so
that we only use the same selector when the containment definitions are
also
the same.
If we just have:
.Foo,
.Bar {
color: red;
}
then this could be compressed down to:
.x1 {
color: red;
}
But if we have:
.Foo,
.Bar {
color: red;
}
.Foo .Joe {
color: green;
}
.Bar .Joe {
color: blue;
}
then we cannot use the same compressed name for Foo and Bar, we'd
compress
to:
.x1,
.x2 {
color: red;
}
.x1 .x3 {
color: green;
}
.x2 .x3 {
color: blue;
}
If we had:
.Foo,
.Bar {
color: red;
}
.Foo .Joe,
.Bar .Joe {
color: green;
}
then we could compress down to:
.x1 {
color: red;
}
.x1 .x2 {
color: green;
}
Yeah that would require quite a lot of evaluation after parsing, if
that's
done maybe we should consider generating the CSS files at app. startup
rather than at first request because that kind of processing would
most like
be O(n!) or O(x^n).
I was thinking if a style is used anywhere else, period, we do not merge
that with another style. That is less processing, at least.
Personally, I think doing the only-generated-compressed-styles solution
or (only-non-uncompressed) is enough to solve this problem for a while.
I think this merging solution is lower priority, and more of a
nice-to-have. What does everyone else think?
If there is another reason to do this, like performance, and we know the
impact, then that's another thing, but I'd like
to focus on this issue and the solution right now -- especially since
we've hit this limit.
- Jeanne
[Skinning] CSS selector limit hit in IE
Hi,
Well, it turns out that IE has a limit to the size of a CSS file. It's
not the actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095
CSS selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that
we've built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors
after the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our
style selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to
the quick fix when I have more time.
Or, I'll be forced to do this solution if the above solution can't be
done for some reason.
Anyway, let me know what you think about the fixes. I'll start
investigating it to make sure it is possible and won't break
anything. My main concern was if people were using our public style
classes, like styleClass=.AFInstructionText, but
it looks like we compress these when we are in compressed mode.
Let me know if there are other things I should check.
Thanks,
Jeanne
Re: [Skinning] CSS selector limit hit in IE
Hi Matt,
Matt Cooper wrote:
Hi Jeanne,
That example of setting styleClass=AFInstructionText (or
styleClass=foo
bar) was the case I was thinking about too and think it should be
okay to
have all compressed and all uncompressed.
To be on the safe side, I just decided that what I can do is if there is
not a '|' in the
name, I will output both compressed/non-compressed. Otherwise, one or
the other.
Having a '|' in the name won't work in css without our preprocessing it,
so no one
would ever use that name outright. But they might use a styleclass like,
.Foo, that
they added to their skin.
If there are any cases where a component developer is writing a
JavaScript
counterpart to their renderer, he or she can send down the resolved style
class along with the rendered content, otherwise they'd just be
hard-coding
a style class which already is bad practice.
In short, it seems like your suggested change wouldn't be a problem
from the
use cases I've seen.
Like you say, in the long term, it would be nice to split it up into
multiple files automatically as an added measure--who knows how many
components Trinidad or customers will have in 5 years or more.
Also, I do prefer to have the generated CSS file be a one or the other
(compressed or not compressed) file rather than both.
ok
As part of this change, can you also add a counter? If the number of
selectors exceeds the limit when generating the IE CSS file, an error or
warning gets logged so that if people are seeing strange behavior,
we'd know
pretty quickly that this is the cause. I think that would be a friendly
thing to do for future developers.
Yes, I was planning to do that as part of the 'quick fix'.
Thanks!
Jeanne
Thank you,
Matt
On 1/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
Well, it turns out that IE has a limit to the size of a CSS file. It's
not the actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095
CSS selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that
we've built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors
after the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our
style selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to
the quick fix when I have more time.
Or, I'll be forced to do this solution if the above solution can't be
done for some reason.
Anyway, let me know what you think about the fixes. I'll start
investigating it to make sure it is possible and won't break
anything. My main concern was if people were using our public style
classes, like styleClass=.AFInstructionText, but
it looks like we compress these when we are in compressed mode.
Let me know if there are other things I should check.
Thanks,
Jeanne
Re: svn commit: r500011 - /incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Adam,
I just noticed this email. I'll ping Scott.
- Jeanne
Adam Winer wrote:
Has this change been tested? I'm far from certain
that this was purely an optimization. We often
check whether there is a PartialPageContext to
see if PPR is enabled, and if this check is removed,
then a lot of code will (I think) assume that PPR
is enabled and available when it is not.
-- Adam
On 1/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jwaldman
Date: Thu Jan 25 14:02:08 2007
New Revision: 500011
URL: http://svn.apache.org/viewvc?view=revrev=500011
Log:
ADFFACES-364 PartialPageContext optimization bug. Check in for Scoot
O'Bryan to jwaldman-portal branch.
Remove this optimization in _initializePPR:
// Don't bother if PPR isn't even supported
if (!CoreRendererUtils.supportsPartialRendering(this))
return;
The reason is commented in the code:
//There used to be an optimization here which would simply return
when
//the PartialRendering capabilities were disabled. This was removed
//because it is possible for extensions to Trinidad to support
PPR in a
//container-specific way in a Portal Environment even though such
capability
//is off by default. Furthermore, the check on whether something
is a
//PPR request or not is very efficient, so there is very little
time saved
//by the optimization.
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java?view=diffrev=500011r1=500010r2=500011
==
---
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
(original)
+++
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Thu Jan 25 14:02:08 2007
@@ -466,9 +466,13 @@
FacesContextfContext,
RequestContext context)
{
-// Don't bother if PPR isn't even supported
-if (!CoreRendererUtils.supportsPartialRendering(this))
- return;
+//There used to be an optimization here which would simply
return when
+//the PartialRendering capabilities were disabled. This was
removed
+//because it is possible for extensions to Trinidad to support
PPR in a
+//container-specific way in a Portal Environment even though
such capability
+//is off by default. Furthermore, the check on whether
something is a
+//PPR request or not is very efficient, so there is very little
time saved
+//by the optimization.
PartialPageContext partialPageContext =
PartialPageUtils.createPartialPageContext(fContext,
Re: Request for FloatStart:alias, FloatEnd:alias
I'm fine with making these public.
Really, to make these public the minimal thing we should do is to
document these keys in skin-selectors.xml and to change the comment to
say they are public instead of private.
We can also change the name to have it start with 'AF' to be consistent
with the other public keys.
- Jeanne
Jijun Wang wrote:
Hello:
In base-desktop.xss, we have the following private styles:
!--
Private BIDI Styles: Not sure if these are generally useful, but
if so, these could be made public.
--
style name=FloatStart
property name=floatleft/property
/style
style name=FloatEnd
property name=floatright/property
/style
FOR RTL Mode:
style name=FloatStart
property name=floatright/property
/style
style name=FloatEnd
property name=floatleft/property
/style
It would be useful to make them public. For example, if I want to
define:
af|foo: {
float: left;
}
af|foo:rtl {
float: right
}
I can define it in one place with the help of the skin key alias of
FloatStart:
af|float: {
-tr-rule-ref: selector(.FloatStart:alias);
}
Could we make the change to have FloatStart:alias and FloatEnd:alias?
Thanks.
Jijun Wang
Re: unknown-version in generated css file
Ok, I figured out what is going on.
If we want our manifest.mf file in our jar to show the implementation
version, then we need to:
1. Add a manifest.mf file in the META-INF directory that has the
implementation-version in it.
2. Add this configuration element to the pom.xml file:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
*configuration
archive
manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration*
executions
execution
goals
goaltest-jar/goal
/goals
/execution
/executions
/plugin
We are missing both of these.
Does anyone object to my adding this to get our version in the
manifest.mf that's in the jar?
Should I do this for the api jar as well?
What should the version string be? This string will be in the generated
css file, at least for now. I plan to raise
another issue regarding the version string in the filename, but that can
wait.
Thanks,
- Jeanne
Jeanne Waldman wrote:
I know how this could work (is supposed to work?), because we are
doing something similar in our internal project . We have a
MANIFEST.MF file in the impl's META-INF directory that defines
implementation-version, and I think mvn automatically appends this
information into the impl jar's MANIFEST.MF file.
In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
META-INF directory. If I add it myself, do mvn clean install, it still
doesn't work. But then after looking into it for our internal project,
I found that it stopped working recently there, too.
Anyway, Bud and I are looking into it, and I'll keep you posted. If
you know something that I am missing, let me know. :)
Thanks,
Jeanne
Jeanne Waldman wrote:
Hi Adam,
That's what I figured based, but I don't see the implementation
version in the manifest.mf.
So I should have asked, how does it get in the manifest.mf file?
Maybe I'm not building the jars with the correct flag.
I'm using mvn install jdev:jdev.
- Jeanne
Adam Winer wrote:
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the
'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion()
!= null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
Re: unknown-version in generated css file
I know how this could work (is supposed to work?), because we are doing
something similar in our internal project . We have a MANIFEST.MF file
in the impl's META-INF directory that defines implementation-version,
and I think mvn automatically appends this information into the impl
jar's MANIFEST.MF file.
In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
META-INF directory. If I add it myself, do mvn clean install, it still
doesn't work. But then after looking into it for our internal project, I
found that it stopped working recently there, too.
Anyway, Bud and I are looking into it, and I'll keep you posted. If you
know something that I am missing, let me know. :)
Thanks,
Jeanne
Jeanne Waldman wrote:
Hi Adam,
That's what I figured based, but I don't see the implementation
version in the manifest.mf.
So I should have asked, how does it get in the manifest.mf file? Maybe
I'm not building the jars with the correct flag.
I'm using mvn install jdev:jdev.
- Jeanne
Adam Winer wrote:
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the 'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion()
!= null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
Re: Skin packaging
Yes, this will work. It was added around November. - Jeanne Mark Robinson wrote: Hi, I'm working on a distributable skin package and I've got some questions. If I wrote a trinidad-skins.xml file and placed in it a jar, would Trinidad be able to merge multiple trinidad-skins.xml files? Sort of like how JSF can merge multiple faces-config.xml. Mark
Re: unknown-version in generated css file
Hi Adam,
That's what I figured based, but I don't see the implementation version
in the manifest.mf.
So I should have asked, how does it get in the manifest.mf file? Maybe
I'm not building the jars with the correct flag.
I'm using mvn install jdev:jdev.
- Jeanne
Adam Winer wrote:
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the 'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion() !=
null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
unknown-version in generated css file
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the 'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion() != null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
Re: [Skinning Enhancement] -tr-icon-class or equivalent
Thanks for the comment. I'll fix that bug so the workaround works. :)
- Jeanne
Adam Winer wrote:
I think, for now, that I'm OK with just requiring inline specification
of the styles - that feels a lot more natural in a CSS file.
At least, as long as it works. :)
-- Adam
On 12/27/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I see the need to render
img class=someClass width=10 height=8/
when we render a skinning icon.
However, there is currently not a way to specify a styleclass in the
skin css file, although we do have a Java API to do this.
We could do something like:
af|foo::some-icon {
content: url(/path/cat.gif);
-tr-icon-class: someClass;
}
Let me know if you think I should/shouldn't open an JIRA enhancement for
this.
This isn't a critical bug, since the workaround is to use css properties
inline, and we parse those up and render an inline style property
like this:
af|foo::some-icon {
content: url(/path/cat.gif);
background-color: blue;
display: block;
}
renders:
img style=background-color:blue; display:block .../
(or should... there's a bug that I filed that I plan to fix where it
only renders the last css property.)
Thanks,
Jeanne
[Skinning Enhancement] -tr-icon-class or equivalent
Hi there,
I see the need to render
img class=someClass width=10 height=8/
when we render a skinning icon.
However, there is currently not a way to specify a styleclass in the
skin css file, although we do have a Java API to do this.
We could do something like:
af|foo::some-icon {
content: url(/path/cat.gif);
-tr-icon-class: someClass;
}
Let me know if you think I should/shouldn't open an JIRA enhancement for
this.
This isn't a critical bug, since the workaround is to use css properties
inline, and we parse those up and render an inline style property like this:
af|foo::some-icon {
content: url(/path/cat.gif);
background-color: blue;
display: block;
}
renders:
img style=background-color:blue; display:block .../
(or should... there's a bug that I filed that I plan to fix where it
only renders the last css property.)
Thanks,
Jeanne
Re: PATCH: ServerSide buttons are back
Hi all, Have we decided that we want to keep the image generation code around, then? Looking back at old emails, it sounds like a couple of people want to keep the rounded-buttons. Thanks, Jeanne Scott O'Bryan wrote: Mark, Yes, he means trinidadinternal.ui. The reason we are getting rid of this is basically a historical reason. These classes are basically a set of adapters designed to port Oracle's old UIX component base over to Faces. As the components were enhanced and expanded, we started turning these components into true Faces Components (which we'll refer to as Faces Major) on this list. While it's acceptable to make enhancements to the UI packages until all the UIX components have been ported over, it is completely wrong to add any new dependencies from outside of these. I haven't taken a look at your patch, but I would take a look at either making your dependancies FacesMajor, or moving the functionality you need from the UI package into a non-ui package and have the UI classes refer to it. Make sense? Scott Mark Robinson wrote: Adam, By myfaces.ui, do you mean trinidadinternal.ui? Is there a reason for getting rid of it? Also, is there migration documentation? Ie, class X is gone, use class Y and Z. Thanks, Mark Adam Winer wrote: Mark, It's not OK for anything in myfaces.trinidadinternal.renderkit to have dependencies on code in myfaces.ui; our goal is to kill all code in myfaces.ui. So, for example: import org.apache.myfaces.trinidadinternal.ui.UIXRenderingContext; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.IconInputStreamProvider ; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.SimpleDesktopConstants ; import org.apache.myfaces.trinidadinternal.uinode.FacesRenderingContext; ... are all off-limits. (Looking through the patch, it looks as though you've added some other imports unnecessarily.) -- Adam No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: 05/12/2006 4:07 PM
When I commit to my branch, it goes to trunk
I'm wondering what I'm doing wrong. I created a branch, but when I commit to it, it commits to trunk. This is the branch. https://svn.apache.org/repos/asf/incubator/adffaces/branches/jwaldman-portal I think I'm on the branch, cuz I say Repro-Browser, and this branch shows up. I made sure I did a Switch to this branch after I created it. When I say Commit, at the top of the Enter Log Message box it says: Commit to: https://svn.apache.org/repos/asf/incubator/adffaces/branches/jwaldman-portal But... I see the commit in Trunk, not my branch. Does anyone know what I'm doing wrong? Thanks! Jeanne
Re: When I commit to my branch, it goes to trunk
I just checked the branch out and retried and that works. I don't know how it got in the state that it is in. I wonder if something is wrong with the Switch function. - Jeanne Matthias Wessendorf wrote: hrm. my commits from branch go never to trunk. What I do is checking the branch out and working on those files. Perhaps the *relocate* or what ever is sorta wrong in your case? -M On 11/28/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I'm wondering what I'm doing wrong. I created a branch, but when I commit to it, it commits to trunk. This is the branch. https://svn.apache.org/repos/asf/incubator/adffaces/branches/jwaldman-portal I think I'm on the branch, cuz I say Repro-Browser, and this branch shows up. I made sure I did a Switch to this branch after I created it. When I say Commit, at the top of the Enter Log Message box it says: Commit to: https://svn.apache.org/repos/asf/incubator/adffaces/branches/jwaldman-portal But... I see the commit in Trunk, not my branch. Does anyone know what I'm doing wrong? Thanks! Jeanne
Re: Bug in XSS Skinning Support
I agree. XSS was the original format, but then we added the CSS-format skinning file thinking that it will be more understandable to a person that would be in charge of the skinning; i.e., someone with css experience. There are features in XSS that aren't yet in CSS, so we should port those over before we kill it. The base skins, like simple/minimal ar using xss. Adam Winer wrote: I agree - while I've got nothing against accepting patches to the XSS code, ideally the XSS code can die ASAP... -- Adam On 11/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Hello, Personally, I hope we'll let it die, especially since inhibit was added to CSS format. On 11/24/06, Mark Robinson [EMAIL PROTECTED] wrote: Hi, I've found a bug in the XSS skinning engine. Specifically, it doesn't recognize Icon descriptors while the CSS skinner does. Right now I'm working on a patch the fix this, but my question is, what is the future of XSS support? Ie, is it going away? Mark
Re: Custom Skins for Different Form Factors
This is fine with me; but I suggested it originally. If anyone has any objections, let us know. - Jeanne Piyush Hari wrote: Hello, I would like to revive the issue with creating custom PDA skins(see emails below). I propose adding the @import support so that a user can create plus-pda skin by extending the simple-pda and importing the plus-Desktop skin. please read the emails below and let me know what you think about this. I will create a JIRA for the same. Take Care, Piyush - Original Message - From: Jeanne Waldman [EMAIL PROTECTED] To: adffaces-dev@incubator.apache.org Sent: Wednesday, August 23, 2006 1:44 PM Subject: Re: Custom Skins for Different Form Factors Hi Joey, We have simple-desktop and simple-pda skins. You can create a pda or desktop skin by specifying the render-kit-id in your skin. The pda skin extends simple-pda skin. The desktop skin extends simple-desktop. You created a plus-desktop skin that extends simple-desktop skin. You like that skin a lot and it has a lot of definitions. Now you need a pda version. You want to use the plus-desktop skin, but you want it to extend simple-pda instead. If you make your plus-pda skin extend plus-desktop skin, it will go through simple-desktop. (you've verified this, right?) You don't want that. You want your plus-pda skin to extend plus-desktop skin, but then you want that to go through simple-pda instead of simple-desktop. I've thought about this some and I think we need a concept of a render-kit-neutral skin. This skin, if picked, will default to extend simple-desktop. But if this skin is used as a base skin for plus-pda, it will eventually extend from simple-pda (the simple skin with the same render-kit-it). Another option is to allow imports in the skinning .css file. So you can import the stylesheet definitions. We have this feature in XSS, which is why you see simple-pda.xss imports simple-desktop.xss. I like the 'abstract' skin idea better. Resource bundles aren't a part of the css file, and you might want to inherit those, too. I don't know how hard/easy it is to implement these ideas. One question, how much will need to change if you forget extending simple-pda, and have your plus-pda skin extend plus-desktop which extends simple-desktop? If it is just a few fonts, then it might easy enough to go that route until we have something in place. Joseph Rozier wrote: Hello, The current method of skin inheritance leads to some issues when a developer wishes to create a skin family targetting desktop and PDA. There's no way to make a large number of changes that affect both desktop and pda in one place, and then tweak what needs to be tweaked for desktop or PDA. For example, I may want to change the color in both desktop and PDA, but I might want to change the font size to 20 for the desktop and 6 for the PDA. The reason for the problem is that each skin can only extend Trinidad's simple skin. There is no way to have an abstract plus skin that makes the common changes, and then have a plus-desktop skin and plus-pda skin that makes desktop/pda specific changes. (Also note that today things are a bit odder, because there's a simple-pda.xss that extends simple-desktop.xss. If I specify a skin in trinidad-skins.xml that is for use with the desktop RenderKit, its css inherits from simple-desktop.xss. If I instead specify its use for the pda RenderKit, its css inherits from simple-pda.xss. However, this doesn't lead to a solution because my plus.css may override a font that is specified in simple-desktop.xss or simple-pda.xss, so that font would now be used on both desktop and pda.) I'm hoping that the skinning experts can provide insights/solutions to this problem. Thanks, Joey
Re: [Question] trinidad-skins.xml in a jar
Arjuna, All,
I like this alternative --the other alternative is to declare the css
file name to be globally unique
like a java class name. We need skinning doc, so I have some place to
'declare' this.
I'll make skin/customSkin.css work instead of META-INF/skin/customSkin.css.
If trinidad-skins.xml is in the META-INF directory, then I'll prepend
META-INF
if there is no initial '/'.
This is what I'll do for now.
Note: URLS, like
http://122.1.1.0:8080/trinidad-demo-context-root/faces/skins/purple/purpleSkins.css
does not work in style-sheet-name currently. That can be a separate
issue if anyone cares.
Thanks,
- Jeanne
Arjuna Wijeyekoon wrote:
the other alternative is to declare the css file name to be globally
unique
like a java class name.
On 11/13/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
also use URL(URL base, String cssFileName) to construct the path rather
than parsing the string yourself.
On 11/13/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
If you think the 'right' way is to have skin/customSkin.css work
instead
+1 for having skin/customSkin.css to work.
then I could do this:
when I get each trinidad-skins.xml in a jar, I get a path like this:
/C:/TestJarTwo/forthebirds.jar!META-INF/trinidad-skins.xml
I could strip out the part before the ! and the /trindad-
skins.xmlpart
and whatever is left I prepend to whatever is in
style-sheet-names, and use that String as the styleSheetName.
This is not going to work. If there was another jar file that also
used
the name customSkin.css
then these two would conflict.
I think you need the entire path right upto the !META-INF .
--arjuna
On 11/13/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Thanks Adam.
see inline
Adam Winer wrote:
On 11/8/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I have two questions about jar'ing up the skins.
Let's say someone has jar'd up their skin and the
trinidad-skins.xml
file.
I have a jar with this directory structure:
META-INF
trinidad-skins.xml
skin
customSkin.css
images
dateButtonPurple.gif
In trinidad-skins.xml, I needed to put META-INF in front of the
path for
the style-sheet-name
style-sheet-name
!-- this doesn't work
skin/customSkin.css
--
META-INF/skin/customSkin.css
/style-sheet-name
Is this correct?
Hrm, well if you're evaluating skin/customSkin.css relative
to the
java.net.URL
used to load the trinidad-skins.xml file, it wouldn't be
necessary.
I'm not. Basically what I do is I parse all the
trinidad-skins.xmlfiles
and get a list of 'skins', which I sort and then register.
styleSheetName is a String. When we load the skin that is set in
trinidad-config.xml (and its ancestor skin files), we
simply look for a file with that String. We end up using
ClassLoaderUtils.getResource() to get the META-INF css files.
If you think the 'right' way is to have skin/customSkin.css work
instead
of META-INF/skin/customSkin.css, then I could do this:
when I get each trinidad-skins.xml in a jar, I get a path like this:
/C:/TestJarTwo/forthebirds.jar!META-INF/trinidad-skins.xml
I could strip out the part before the ! and the /trindad-
skins.xmlpart
and whatever is left I prepend to whatever is in
style-sheet-names, and use that String as the styleSheetName.
Unless there is some easy call that exists that I am missing.
- Jeanne
Also, I don't know how the browser is supposed to find the images
out of
this jar, where
af|inputDate::launch-icon
{
content:url(images/dateButtonPurple.gif);
width:19px;
height:24px
}
The url is:
src=/trinidad-demo-context-root/skin/images/dateButtonPurple.gif
0on't think that's gonna work: we'd need to have a ResourceLoader
that could reach into JARs. We haven't built such a thing. Would
be
handy, but I don't think that's an immediate requirement. For
now,
I think of just saying that we only support image URLs that start
with a slash (and therefore relative to the context root) in this
scenario.
-- Adam
I tried putting META-INF and 'adf/' in the path, but that didn't
work.
- Jeanne
Jeanne Waldman wrote:
By the way, I'm going to break this into two issues:
1. enable trinidad-skins.xml to be in META-INF directory and
therefore
it can be read out of jars.
a. first find all trinidad-skins.xml files in
META-INF/trinidad- skins.xml
b. then look for it in WEB-INF/trinidad-skins.xml. The one
that is
in WEB-INF 'wins'.
c. with regards to 'wins'. If I have a skin definition
that is
the
SAME skin id, but with different parameters,
then the one in WEB-INF wins. If I find two in a jar,
then
which one should win? The last one I load
Re: [Question] trinidad-skins.xml in a jar
Thanks Adam.
see inline
Adam Winer wrote:
On 11/8/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I have two questions about jar'ing up the skins.
Let's say someone has jar'd up their skin and the trinidad-skins.xml
file.
I have a jar with this directory structure:
META-INF
trinidad-skins.xml
skin
customSkin.css
images
dateButtonPurple.gif
In trinidad-skins.xml, I needed to put META-INF in front of the path for
the style-sheet-name
style-sheet-name
!-- this doesn't work
skin/customSkin.css
--
META-INF/skin/customSkin.css
/style-sheet-name
Is this correct?
Hrm, well if you're evaluating skin/customSkin.css relative to the
java.net.URL
used to load the trinidad-skins.xml file, it wouldn't be necessary.
I'm not. Basically what I do is I parse all the trinidad-skins.xml files
and get a list of 'skins', which I sort and then register.
styleSheetName is a String. When we load the skin that is set in
trinidad-config.xml (and its ancestor skin files), we
simply look for a file with that String. We end up using
ClassLoaderUtils.getResource() to get the META-INF css files.
If you think the 'right' way is to have skin/customSkin.css work instead
of META-INF/skin/customSkin.css, then I could do this:
when I get each trinidad-skins.xml in a jar, I get a path like this:
/C:/TestJarTwo/forthebirds.jar!META-INF/trinidad-skins.xml
I could strip out the part before the ! and the /trindad-skins.xml part
and whatever is left I prepend to whatever is in
style-sheet-names, and use that String as the styleSheetName.
Unless there is some easy call that exists that I am missing.
- Jeanne
Also, I don't know how the browser is supposed to find the images out of
this jar, where
af|inputDate::launch-icon
{
content:url(images/dateButtonPurple.gif);
width:19px;
height:24px
}
The url is:
src=/trinidad-demo-context-root/skin/images/dateButtonPurple.gif
0on't think that's gonna work: we'd need to have a ResourceLoader
that could reach into JARs. We haven't built such a thing. Would be
handy, but I don't think that's an immediate requirement. For now,
I think of just saying that we only support image URLs that start
with a slash (and therefore relative to the context root) in this
scenario.
-- Adam
I tried putting META-INF and 'adf/' in the path, but that didn't work.
- Jeanne
Jeanne Waldman wrote:
By the way, I'm going to break this into two issues:
1. enable trinidad-skins.xml to be in META-INF directory and therefore
it can be read out of jars.
a. first find all trinidad-skins.xml files in
META-INF/trinidad-skins.xml
b. then look for it in WEB-INF/trinidad-skins.xml. The one that is
in WEB-INF 'wins'.
c. with regards to 'wins'. If I have a skin definition that is the
SAME skin id, but with different parameters,
then the one in WEB-INF wins. If I find two in a jar, then
which one should win? The last one I load?
I will do something like that and log a warning.
Another thing I can do is try to merge the information, but I
think this can get confusing.
2. custom component registering skin additions in trinidad-skins.xml
- Jeanne
Jeanne Waldman wrote:
I was thinking about whether we should use the same file, and the pro
of using the same file --
fewer files is really good. The cons, they are aimed at different
users.
A custom component developer will want to add to existing skins, not
create new skins.
I'll go with the fewer files is really good outweighing the different
users argument. :)
Simon, the reason I didn't opt for skin-extension is that we have a
SkinExtension class - it's creating
a new skin that extends an existing skin.
What I want is to use the same skin, and add new component skin
definitions to it.
I'm not sure what a good name for it is.
Right now I look for trinidad-skins.xml in
web-inf, and I +1 to looking for in in META-INF as well. And yes,
if there can be multiple trinidad-skins.xml files laying around, I'll
need to worry
about order. And... I'll have to make sure that all the skins are
there before I register
the skin additions. I'll need to parse these files and buffer up the
information, then
order them, then register things.
Thanks for the feedback.
- Jeanne
Adam Winer wrote:
I don't think it should be a separate file; it should be a new
element in trinidad-skins.xml. And +1 to Simon's request
for /META-INF support.
This way, you could use a /META-INF/trinidad-skins.xml
file to provide drop-in JARs that provide:
- skin extensions
- new skins
One big bit of fun: you could have one /META-INF/trinidad-skins.xml
that defines a new my-amazing-skin, and a second JAR
that defines a new even-better-skin that extends
my-amazing-skin,
and a third JAR that defines extensions to even-better-skin.
And you'd have to support the jars getting doled out third, second,
first by the class
[Question] trinidad-skins.xml in a jar
I have two questions about jar'ing up the skins.
Let's say someone has jar'd up their skin and the trinidad-skins.xml file.
I have a jar with this directory structure:
META-INF
trinidad-skins.xml
skin
customSkin.css
images
dateButtonPurple.gif
In trinidad-skins.xml, I needed to put META-INF in front of the path for
the style-sheet-name
style-sheet-name
!-- this doesn't work
skin/customSkin.css
--
META-INF/skin/customSkin.css
/style-sheet-name
Is this correct?
Also, I don't know how the browser is supposed to find the images out of
this jar, where
af|inputDate::launch-icon
{
content:url(images/dateButtonPurple.gif);
width:19px;
height:24px
}
The url is:
src=/trinidad-demo-context-root/skin/images/dateButtonPurple.gif
I tried putting META-INF and 'adf/' in the path, but that didn't work.
- Jeanne
Jeanne Waldman wrote:
By the way, I'm going to break this into two issues:
1. enable trinidad-skins.xml to be in META-INF directory and therefore
it can be read out of jars.
a. first find all trinidad-skins.xml files in
META-INF/trinidad-skins.xml
b. then look for it in WEB-INF/trinidad-skins.xml. The one that is
in WEB-INF 'wins'.
c. with regards to 'wins'. If I have a skin definition that is the
SAME skin id, but with different parameters,
then the one in WEB-INF wins. If I find two in a jar, then
which one should win? The last one I load?
I will do something like that and log a warning.
Another thing I can do is try to merge the information, but I
think this can get confusing.
2. custom component registering skin additions in trinidad-skins.xml
- Jeanne
Jeanne Waldman wrote:
I was thinking about whether we should use the same file, and the pro
of using the same file --
fewer files is really good. The cons, they are aimed at different users.
A custom component developer will want to add to existing skins, not
create new skins.
I'll go with the fewer files is really good outweighing the different
users argument. :)
Simon, the reason I didn't opt for skin-extension is that we have a
SkinExtension class - it's creating
a new skin that extends an existing skin.
What I want is to use the same skin, and add new component skin
definitions to it.
I'm not sure what a good name for it is.
Right now I look for trinidad-skins.xml in
web-inf, and I +1 to looking for in in META-INF as well. And yes,
if there can be multiple trinidad-skins.xml files laying around, I'll
need to worry
about order. And... I'll have to make sure that all the skins are
there before I register
the skin additions. I'll need to parse these files and buffer up the
information, then
order them, then register things.
Thanks for the feedback.
- Jeanne
Adam Winer wrote:
I don't think it should be a separate file; it should be a new
element in trinidad-skins.xml. And +1 to Simon's request
for /META-INF support.
This way, you could use a /META-INF/trinidad-skins.xml
file to provide drop-in JARs that provide:
- skin extensions
- new skins
One big bit of fun: you could have one /META-INF/trinidad-skins.xml
that defines a new my-amazing-skin, and a second JAR
that defines a new even-better-skin that extends my-amazing-skin,
and a third JAR that defines extensions to even-better-skin.
And you'd have to support the jars getting doled out third, second,
first by the class loader. So, the parsing code would need to
do some juggling to make sure this all works.
-- Adam
On 11/6/06, Simon Lessard [EMAIL PROTECTED] wrote:
+1
As for the name, maybe skin-extension? skin-addition is as good
however.
About the structure, I would like to see those placed in
trinidad-skins.xmlalong with the skins. I think we should also extends
our lookup to include
.jar files' /META-INF folder if we don't already do it since it'll
be needed
for developper wanting to deploy simple skin compliant libraries.
Regards,
~ Simon
On 11/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
Let's say a custom component developer created some new
components. He
wants those components to fit in with the
'simple' skin. He also wants them to fit in with the 'minimal'
skin
or any other public skin out there. He doesn't have access to
the files
where we
have this information -- our base-desktop.xss, simple-desktop.xss,
simple-pda.xss, etc.
With Trinidad's Skin API, he can call the
skin.registerStyleSheet
(META-INF/styles/myCustomComponentsSimpleDesktop.css)
method on the skin instance. Aside: I'm not sure *when/where* the
custom
component developer would do this, because it would need to be
after we've
registered our base skins and any skin extensions, so presumably it
would need to be after the TrinidadFilter.
It would be much nicer for the custom component developer if all
he has
to do is create an .xml file and stick it in the META-INF
of his jar file. Then we'll parse the xml file
Re: [Proposal] new skin config file for adding stylesheet with a skin
I was thinking about whether we should use the same file, and the pro of using the same file -- fewer files is really good. The cons, they are aimed at different users. A custom component developer will want to add to existing skins, not create new skins. I'll go with the fewer files is really good outweighing the different users argument. :) Simon, the reason I didn't opt for skin-extension is that we have a SkinExtension class - it's creating a new skin that extends an existing skin. What I want is to use the same skin, and add new component skin definitions to it. I'm not sure what a good name for it is. Right now I look for trinidad-skins.xml in web-inf, and I +1 to looking for in in META-INF as well. And yes, if there can be multiple trinidad-skins.xml files laying around, I'll need to worry about order. And... I'll have to make sure that all the skins are there before I register the skin additions. I'll need to parse these files and buffer up the information, then order them, then register things. Thanks for the feedback. - Jeanne Adam Winer wrote: I don't think it should be a separate file; it should be a new element in trinidad-skins.xml. And +1 to Simon's request for /META-INF support. This way, you could use a /META-INF/trinidad-skins.xml file to provide drop-in JARs that provide: - skin extensions - new skins One big bit of fun: you could have one /META-INF/trinidad-skins.xml that defines a new my-amazing-skin, and a second JAR that defines a new even-better-skin that extends my-amazing-skin, and a third JAR that defines extensions to even-better-skin. And you'd have to support the jars getting doled out third, second, first by the class loader. So, the parsing code would need to do some juggling to make sure this all works. -- Adam On 11/6/06, Simon Lessard [EMAIL PROTECTED] wrote: +1 As for the name, maybe skin-extension? skin-addition is as good however. About the structure, I would like to see those placed in trinidad-skins.xmlalong with the skins. I think we should also extends our lookup to include .jar files' /META-INF folder if we don't already do it since it'll be needed for developper wanting to deploy simple skin compliant libraries. Regards, ~ Simon On 11/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, Let's say a custom component developer created some new components. He wants those components to fit in with the 'simple' skin. He also wants them to fit in with the 'minimal' skin or any other public skin out there. He doesn't have access to the files where we have this information -- our base-desktop.xss, simple-desktop.xss, simple-pda.xss, etc. With Trinidad's Skin API, he can call the skin.registerStyleSheet (META-INF/styles/myCustomComponentsSimpleDesktop.css) method on the skin instance. Aside: I'm not sure *when/where* the custom component developer would do this, because it would need to be after we've registered our base skins and any skin extensions, so presumably it would need to be after the TrinidadFilter. It would be much nicer for the custom component developer if all he has to do is create an .xml file and stick it in the META-INF of his jar file. Then we'll parse the xml file and register the stylesheets with the skins for him. *Does anyone object to a new .xml file for custom component skin additions?* Also, we'll need to discuss the 'api' -- the name and format of the file. This is what I have right now . The purpose of the file is for custom component developers to add skinning information for their custom components to a specific, existing skin. Any name suggestions are welcome! *trinidad-skin-additions.xml* ?xml version=1.0? skin-additions xmlns=http://myfaces.apache.org/trinidad/skin; skin-addition skin-id simple.desktop /skin-id style-sheet-name META-INF/myStyles/skin/customSkin/myCustomComponentsSimpleDesktop.css /style-sheet-name /skin-addition skin-addition skin-id minimal.desktop /skin-id style-sheet-name META-INF/myStyles/skin/customSkin/myCustomComponentsMinimalDesktop.css /style-sheet-name /skin-addition /skin-additions For comparison, here's the trinidad-skins.xml file: skins xmlns=http://myfaces.apache.org/trinidad/skin; skin id purple.desktop /id family purple /family render-kit-id org.apache.myfaces.trinidad.desktop /render-kit-id style-sheet-name skins/purple/purpleSkin.css /style-sheet-name bundle-name org.apache.myfaces.trinidaddemo.resource.SkinBundle /bundle-name /skin /skins Thanks a lot, Jeanne
excess parsers
Hi there, I see there are a lot of parsers that I'm 99.9% sure we no longer use. We used to use them before Trinidad was Trinidad and was UIX. They are all the parsers in the org.apache.myfaces.trinidadinternal.ui.laf.xml.parse package. Is there a reason that these are still around? I don't need it for skinning. I can create an issue to delete these files and their references if everyone is ok with it. - Jeanne
Re: excess parsers
Except for SkinExtensionParser, that's still used, although it will change some after I do my work. I'll create an issue for the other ones. - Jeanne Adam Winer wrote: Yep, I don't think those are used anymore. -- Adam On 11/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I see there are a lot of parsers that I'm 99.9% sure we no longer use. We used to use them before Trinidad was Trinidad and was UIX. They are all the parsers in the org.apache.myfaces.trinidadinternal.ui.laf.xml.parse package. Is there a reason that these are still around? I don't need it for skinning. I can create an issue to delete these files and their references if everyone is ok with it. - Jeanne
Re: panelBox and simple skin
Hi Simon,
I just read this thread, and I was going to suggest using an alias.
I think your idea is fine.
- Jeanne
Simon Lessard wrote:
Hello again,
I thought about a 4) last night for this, I could also import
af|panelBox::body in the 4 selectors, basically using it as an alias.
Is it
reasonable?
On 10/30/06, Simon Lessard [EMAIL PROTECTED] wrote:
Yes we got one. I'll add the issue a bit later tonight.
On 10/30/06, Adam Winer [EMAIL PROTECTED] wrote:
I agree... though this is confusing... I can't
think of anything better, though.
Do we have a Wiki page yet for skinning? This'd
be a good thing to throw up there.
-- Adam
On 10/30/06, Simon Lessard [EMAIL PROTECTED] wrote:
Hello all,
There was a post this morning about a skin selector not working in
panelBox
(my implementation). Anyway, the user was trying to use the
following:
af|panelBox::body {
background-color: black;
}
However, the background was not changing. This is because simple
skin
defines af|panelBox::light af|panelBox::body {background-color:
aColor;}
and
it get generated after the root selector in the final CSS, thus
giving
it
priority.
There's three way to fix that:
1) Users can overload the 4 selectors (for each background) to
set the
desired color;
2) Users can use af|panelBox::body, but overload all 4 other body
selectors
in order to inhibit the inherited property;
3) Remove colors from simple skin and move them to minimal instead.
Personally I think users should opt for 2) and we should not change
simple
skin. Anyone has comments about that?
Regards,
~ Simon
Re: making IntegerUtils part of API ?
+1 Matthias Wessendorf wrote: +1 On 10/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey, any one care to make IntegerUtils from trinidad-impl part of the public API? I like to use it in the api, when working on the validator/converter *overhaul* issue(s). the javadoc says: Class containing various integer utilities. It caches commonly used Integer objects and String representations of Integers to avoid expensive object creations. (and also...) IntegerUtils is used throughout most Bali projects, and clients are also encouraged to use it for increased performance. :-) Thanks, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Build Error - test failure
I don't know, but I'd try doing a 'mvn clean' first. Did you do this? What were the golden file diffs? Maybe that will give a clue. Piyush Hari wrote: Hello, To fix a commandButton ,presently not rendering on a Pocket IE or IE Mobile browser, I changed the following agent capability in pocketie.xml from 'true' to 'false' capability name=-adfinternal-advancedForms value=false/ When I built with tests OFF, it worked fine - button displayed and fully functional. When I built it with tests ON, it gave me test failures. I copy-pasted the test failure files into the golden directory and built again. Again, it gave me test failures. Any leads on this ? How do I determine what is going wrong ? Here is the stack trace : [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] There are test failures. [INFO] - --- [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: There are test failures. at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more [INFO] - Regards, Piyush
Re: svn commit: r451772 [1/8] - in /incubator/adffaces/trunk/trinidad: src/site/xdoc/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/desktop/ trinidad-impl/src/main/jav
I might be assuming something that is not correct, so let me ask, in the case of the train, what part is delegating to the navigationItem renderer? I'm assuming the af|train::link part. So, regardless of the skinning syntax (af|train::stop::link or af|train::stop af|train::link) you would map af|navigationItem to af|train::link. The af|train::stop/p_AFUnvisited, and p_AFReadOnly are still within the train renderer, right? So there is no need put those on the resource map. If we used af|train::stop::link format, the css parser would break it apart, and it would end up to be the same as if the skinner wrote af|train::stop af|train::link. Same with af|train::stop:unvisited:read-only::link. We'd break it apart and make it be: af|tarin::stop:unvisited:read-only af|train::link It's like how the user types this: af|inputText:read-only::content and we resolve it to this: af|inputText:read-only af|inputText::content - Jeanne Simon Lessard wrote: Linking af|train::link to navigation item alone would not be enough with af|train::stop::link. This is currently what I use, another why I used a single selecor for all links. However take af|train::stop:unvisited:read-only::link The only way I see would be to set all 3 selectors on the resource map (af|train::stop::link, p_AFUnvisited and p_AFReadOnly) for both link seletors (disabled and normal). The main disadvantage with that is that it requires the use of one map instance per station being rendered, which will be much less efficient than the currently singleton map. Regards, ~ Simon On 10/4/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Simon Lessard wrote: Hello all, Well, at first I made it that way beause dual pseudo-element was completely removed because it was buggy. yep, we never had keys with multi-pseudo-elements, so it wasn't written to support it. However, now that it was made that way I don't dislike it. It depends how you see the link I guess, both have a semantic sense. That being said, on a practical side, the current version is much easier since the link rendering is deferred to the navigationItem renderer so pushing complex style class in it can be problematic. For instance, how would it be possible to emulate the following using resource map? af|train::stop:unvisited:read-only af|train::link You would map af|train::link to af|navigationItem. The new version of the selector would be af|train::stop:unvisited:read-only::link, but I don'T know if the current architecture could support that. The parser would have to change, definitely to support it. We can leave this issue alone for now, since there are so many more important issues to work out. Regards, ~ Simon On 10/4/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I wonder if we should support multiple pseudo-elements. That is, I wonder if : af|train::stop af|train::link af|train::overflow-start af|train::link af|train::overflow-end af|train::link would make more css-sense if the skinning definition was instead af|train::stop::link af|train::overflow-start::link af|train::overflow-end::link The top bunch seems to say style the train's link for the train that is inside the other train's stop. Up until now I have said that multiple pseudo-elements is illegal. I don't see it used in the css spec at all. But it seems to me that it fits the css syntax more than the top definition. What do people think? Some background: I used to have this: af|inputText:disabled af|inputText::content and a team member pointed out that it makes more css sense to have this: af|inputText:disabled::content. So I changed the definition to be af|inputText:disabled::content, but the parser still parses it to af|inputText:disabled af|inputText::content and it gets generated to .af_inputText.p_AFDisabled .af_inputText_content. Pavitra Subramaniam wrote: I didn't realize that it was going to be used this way. We don't need the stop-link like I suggested. Thanks - Pavitra
Re: svn commit: r451772 [1/8] - in /incubator/adffaces/trunk/trinidad: src/site/xdoc/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/desktop/ trinidad-impl/src/main/jav
Simon Lessard wrote: Hello all, Well, at first I made it that way beause dual pseudo-element was completely removed because it was buggy. yep, we never had keys with multi-pseudo-elements, so it wasn't written to support it. However, now that it was made that way I don't dislike it. It depends how you see the link I guess, both have a semantic sense. That being said, on a practical side, the current version is much easier since the link rendering is deferred to the navigationItem renderer so pushing complex style class in it can be problematic. For instance, how would it be possible to emulate the following using resource map? af|train::stop:unvisited:read-only af|train::link You would map af|train::link to af|navigationItem. The new version of the selector would be af|train::stop:unvisited:read-only::link, but I don'T know if the current architecture could support that. The parser would have to change, definitely to support it. We can leave this issue alone for now, since there are so many more important issues to work out. Regards, ~ Simon On 10/4/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I wonder if we should support multiple pseudo-elements. That is, I wonder if : af|train::stop af|train::link af|train::overflow-start af|train::link af|train::overflow-end af|train::link would make more css-sense if the skinning definition was instead af|train::stop::link af|train::overflow-start::link af|train::overflow-end::link The top bunch seems to say style the train's link for the train that is inside the other train's stop. Up until now I have said that multiple pseudo-elements is illegal. I don't see it used in the css spec at all. But it seems to me that it fits the css syntax more than the top definition. What do people think? Some background: I used to have this: af|inputText:disabled af|inputText::content and a team member pointed out that it makes more css sense to have this: af|inputText:disabled::content. So I changed the definition to be af|inputText:disabled::content, but the parser still parses it to af|inputText:disabled af|inputText::content and it gets generated to .af_inputText.p_AFDisabled .af_inputText_content. Pavitra Subramaniam wrote: I didn't realize that it was going to be used this way. We don't need the stop-link like I suggested. Thanks - Pavitra
Re: [jira] Commented: (ADFFACES-56) change -ora-* skinning properties to have another prefix
Yeah, I was just thinking -tr- seems like tr. Matthias Wessendorf wrote: forward to adffaces-dev On 10/4/06, Simon Lessard [EMAIL PROTECTED] wrote: Hmm, I don't know, properties will look like -tr-visible-stop-count in the skin. Personally, I don't see the markup easily in there. I'm completely +0 about that. On 10/4/06, Jeanne Waldman (JIRA) adffaces-issues@incubator.apache.org wrote: [ http://issues.apache.org/jira/browse/ADFFACES-56?page=comments#action_12439876] Jeanne Waldman commented on ADFFACES-56: I committed the above change. I can change it if we decide we don't like -tr- change -ora-* skinning properties to have another prefix Key: ADFFACES-56 URL: http://issues.apache.org/jira/browse/ADFFACES-56 Project: MyFaces ADF-Faces Issue Type: Improvement Reporter: Jeanne Waldman Assigned To: Jeanne Waldman The -ora- prefix needs to be changed. Suggestions: -oam- (for org apache myfaces) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Process train and IE
Simon,
Your workaround is fine. Pavitra submitted a bug internally for this,
but there should be an JIRA issue created if it hasn't been already,
then such hacks can refer to the issue number.
I'm planning to start on the discussion/resolution of this bug very
soon, cuz we are using composite selectors all over the place for our
internal renderers, so we'll be hearing about it if we don't fix this soon.
Thanks,
Jeanne
Simon Lessard wrote:
A browser sepcific key would not help in this case as the problem come
from
the evaluation of a state (autogenerated from :state structure) style
class.
Regards,
~ Simon
On 9/27/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Can't we add a browser specific skinning key for this?
Scott
Arjuna Wijeyekoon wrote:
I think this is fine.
+1
one thing is to check to see if there already is a utility method to
figure
out if the agent is IE.
--arjuna
On 9/27/06, Simon Lessard [EMAIL PROTECTED] wrote:
My patch is extremely specific to process train, so you won't be able
to
apply it directly in any other problem. The main idea behind it is
that
the
composite selectors cause problems for joins on the content row
mainly and
that joins are background images 99% of the times. So, for IE I
add the
following to the content row:
/* -= Simon =-
* FIXME HACK for MSIE CSS bug involving composite style classes.
* Since the bug is most obvious with join background
images,
* I hard code them to none
*/
if(arc.getAgent().getAgentName().equalsIgnoreCase(Agent.AGENT_IE))
{
writer.writeAttribute(XhtmlConstants.STYLE_ATTRIBUTE,
background-image:none;,
null);
}
Note that I didn't check IE version, I just assume that IE never
works.
Regards,
~Simon
On 9/26/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
thanks Pavitra,
Simon, can you post an example of what your patch markup looks
like?
On 9/26/06, Pavitra Subramaniam [EMAIL PROTECTED]
wrote:
This is certainly on IE6. But I haven't tried IE7. Here is an
example
html
head
titletrain Demo/title
style type=text/css
.af_train_stop-link.p_AFVisited{text-decoration:underline
;color:red;background-color:transparent;}
.af_train_stop-spacer.p_AFVisited{background-color:red}
/style
/head
body class=
table cellpadding=0 cellspacing=0 border=0 summary=
class=af_train
tbody
tr
tddiv class=af_train_stop-spacer
p_AFVisited/div/td
td/td
/tr
tr
tddiv class=af_train_stop-content
a class=af_train_stop-link p_AFVisited
onclick=return
false;First Step/a/div/td
td/td
/tr
/tbody
/table
/body
/html
- Pavitra
-Original Message-
From: Arjuna Wijeyekoon [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 1:30 PM
To: adffaces-dev@incubator.apache.org
Subject: Re: Process train and IE
is this IE 6 or IE 7?
On 9/23/06, Simon Lessard [EMAIL PROTECTED] wrote:
Hello all,
As you might know, IE has some problems with composite
selectors
(.something.somethingElse for example, but more commonly
.af_train_stop.p_AFVisited). With process train the most
important
issue it yield is showing the stop join on the content row
because of
how IE evaluate those selectors. I was able to patch it
writing an
hard coded style on the content row, is that something
acceptable?.
Regards,
~ Simon
Re: Process train and IE
Thanks Simon I really appreciate all your help with the skinning stuff.
Jeanne
Simon Lessard wrote:
Alright,
Thank Jeanne. I don't think a JIRA issue was opened yet, I'll do that
tonight and change the reference in me FIXME to that issue.
Regards,
~ Simon
On 9/27/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Simon,
Your workaround is fine. Pavitra submitted a bug internally for this,
but there should be an JIRA issue created if it hasn't been already,
then such hacks can refer to the issue number.
I'm planning to start on the discussion/resolution of this bug very
soon, cuz we are using composite selectors all over the place for our
internal renderers, so we'll be hearing about it if we don't fix this
soon.
Thanks,
Jeanne
Simon Lessard wrote:
A browser sepcific key would not help in this case as the problem come
from
the evaluation of a state (autogenerated from :state structure)
style
class.
Regards,
~ Simon
On 9/27/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Can't we add a browser specific skinning key for this?
Scott
Arjuna Wijeyekoon wrote:
I think this is fine.
+1
one thing is to check to see if there already is a utility
method to
figure
out if the agent is IE.
--arjuna
On 9/27/06, Simon Lessard [EMAIL PROTECTED] wrote:
My patch is extremely specific to process train, so you won't be
able
to
apply it directly in any other problem. The main idea behind it is
that
the
composite selectors cause problems for joins on the content row
mainly and
that joins are background images 99% of the times. So, for IE I
add the
following to the content row:
/* -= Simon =-
* FIXME HACK for MSIE CSS bug involving composite style
classes.
* Since the bug is most obvious with join background
images,
* I hard code them to none
*/
if(arc.getAgent().getAgentName().equalsIgnoreCase(Agent.AGENT_IE))
{
writer.writeAttribute(XhtmlConstants.STYLE_ATTRIBUTE,
background-image:none;,
null);
}
Note that I didn't check IE version, I just assume that IE never
works.
Regards,
~Simon
On 9/26/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
thanks Pavitra,
Simon, can you post an example of what your patch markup looks
like?
On 9/26/06, Pavitra Subramaniam [EMAIL PROTECTED]
wrote:
This is certainly on IE6. But I haven't tried IE7. Here is an
example
html
head
titletrain Demo/title
style type=text/css
.af_train_stop-link.p_AFVisited{text-decoration:underline
;color:red;background-color:transparent;}
.af_train_stop-spacer.p_AFVisited{background-color:red}
/style
/head
body class=
table cellpadding=0 cellspacing=0 border=0
summary=
class=af_train
tbody
tr
tddiv class=af_train_stop-spacer
p_AFVisited/div/td
td/td
/tr
tr
tddiv class=af_train_stop-content
a class=af_train_stop-link p_AFVisited
onclick=return
false;First Step/a/div/td
td/td
/tr
/tbody
/table
/body
/html
- Pavitra
-Original Message-
From: Arjuna Wijeyekoon [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 1:30 PM
To: adffaces-dev@incubator.apache.org
Subject: Re: Process train and IE
is this IE 6 or IE 7?
On 9/23/06, Simon Lessard [EMAIL PROTECTED] wrote:
Hello all,
As you might know, IE has some problems with composite
selectors
(.something.somethingElse for example, but more commonly
.af_train_stop.p_AFVisited). With process train the most
important
issue it yield is showing the stop join on the content row
because of
how IE evaluate those selectors. I was able to patch it
writing an
hard coded style on the content row, is that something
acceptable?.
Regards,
~ Simon
Re: new method on Skin class; new method on Icon class.
Thanks Adam, I realized that after sending this initial email, and now I have no need to get all the icons because I plan to go a different route to getting the icons to the client, so I am not planning to implement this api now. - Jeanne Adam Winer wrote: getIcons() makes sense. But getContent() - it'd be sufficient to clone the current ResponseWriter with a StringWriter, and get the contents that way. -- Adam On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Actually, my question is, I need a new method on the Skin class, getIcons(). And in the Icon class, I need a new method, getContent(). This is for our client-side rendering, where we need to pass icon information to the client. I need to get all icons that are on the skin, and get the content (img src... or TextIcon info) to send to the client. Also, I'm playing with the idea of generating the img markup in a way so that the stuff the renderer specifies goes on a span and the stuff that comes from the skinning definition goes on the img. This way we have a cleaner separation of what came from the skin and what properties are from the skin's icon definition. This will come in useful for our client-side rendering, as well. We'd only need to pass the icon markup that came from the skin to the client. Thoughts on this one? (I'll probably need to add a getProperties() api as well, but one step at a time) Thanks! - Jeanne Simon Lessard wrote: I will be all for a new Skin API, let make it an independant module! On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I can see your point about ending with 'icon' being confusing, but I prefer to leave this alone for now. I'll go ahead and add support for the :hover/etc on the icon skinning keys. (I have another issue that goes with this one (new Skin api), but I'll start a new thread) - Jeanne
Re: Pending PDA Patches
Hi Joey, I haven't had time to respond. I don't know what the dependency method should be. Your suggestion: Is it acceptable to locally apply the earlier patch that has not yet been committed and, in effect, include that patch in a new patch? I think this is acceptable, because I don't think this new patch would get reviewed until the first patch that it depends on gets checked in. So then when we review the second patch, the differences won't be the differences of both patches, just the second patch. - Jeanne Joseph Rozier wrote: Hello, I'm resending this since there was no response to the first one... I'd particularly appreciate a response to what the desired way to handle patch dependencies is, when one patch is dependent on another patch that has not yet been committed. (The review/committing of the outstanding PDA patches would be appreciated as well. :)) Thanks, Joey On 9/13/06, Joseph Rozier [EMAIL PROTECTED] wrote: Hello, The following two JIRAs have patches waiting to be reviewed/committed. https://issues.apache.org/jira/browse/ADFFACES-167 Add 'autoSubmit' support for basic input components on PDAs https://issues.apache.org/jira/browse/ADFFACES-110 Add Agent for BlackBerry Browser 4.0 (this has a fix to the original patch) Would it be possible to get these two patches committed? We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go, but they have dependencies on these patches. Also, for the future, what is the protocol for submitting patches that have dependencies on earlier patches that have not yet been committed. Is it acceptable to locally apply the earlier patch that has not yet been committed and, in effect, include that patch in a new patch? I can see how that would make patch reviewing a headache, but we're running into the issue where a lot of the PDA patches have dependences on earlier patches and it typically takes several days to get even minor changes reviewed and committed. Thanks, Joey
Re: Pending PDA Patches
I have a question regarding pda code.
In Faces Major renderers, do we add pda hooks into the renderer, or
should we have separate pda renderers?
I was looking at the pda patch for autoSubmit, and I see this code in
FormRenderer. Do we have a rule as to when we
should use a pda renderer instead of these hooks? Is it a judgement call
in how much the code differs?
Thanks,
Jeanne
if (isPIE pprContext == null)
{
+ //PH: Add hidden elements in the form for enabling PPR on IE Mobile.
+
+ Object domLevel =
arc.getAgent().getCapability(TrinidadAgent.CAP_DOM);
+
+ if(
+ domLevel == null ||
+ domLevel == TrinidadAgent.DOM_CAP_NONE ||
+ domLevel == TrinidadAgent.DOM_CAP_FORM)
+ {
+FormData formData = arc.getFormData();
+if(formData != null)
+{
+ formData.addNeededValue(XhtmlConstants.EVENT_PARAM);
+ formData.addNeededValue(XhtmlConstants.SOURCE_PARAM);
+ formData.addNeededValue(XhtmlConstants.PARTIAL_TARGETS_PARAM);
+ formData.addNeededValue(XhtmlConstants.PARTIAL_PARAM);
+}
+ }
+
Jeanne Waldman wrote:
Hi Joey,
I haven't had time to respond.
I don't know what the dependency method should be.
Your suggestion:
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I think this is acceptable, because I don't think this new patch would
get
reviewed until the first patch that it depends on gets checked in.
So then when we review the second patch, the differences won't be the
differences of both patches, just the second patch.
- Jeanne
Joseph Rozier wrote:
Hello,
I'm resending this since there was no response to the first one...
I'd particularly appreciate a response to what the desired way to
handle patch dependencies is, when one patch is dependent on another
patch that has not yet been committed. (The review/committing of the
outstanding PDA patches would be appreciated as well. :))
Thanks,
Joey
On 9/13/06, Joseph Rozier [EMAIL PROTECTED] wrote:
Hello,
The following two JIRAs have patches waiting to be reviewed/committed.
https://issues.apache.org/jira/browse/ADFFACES-167
Add 'autoSubmit' support for basic input components on PDAs
https://issues.apache.org/jira/browse/ADFFACES-110
Add Agent for BlackBerry Browser 4.0
(this has a fix to the original patch)
Would it be possible to get these two patches committed?
We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
but they have dependencies on these patches.
Also, for the future, what is the protocol for submitting patches that
have dependencies on earlier patches that have not yet been committed.
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I can see how that would make patch reviewing a headache, but we're
running into the issue where a lot of the PDA patches have dependences
on earlier patches and it typically takes several days to get even
minor changes reviewed and committed.
Thanks,
Joey
Re: IconRenderer
I see now what the old IconRenderer is used for; the shuttle renderers are not yet faces-major and they use the old IconRenderer code. Simon Lessard wrote: We have many old renderers in the ui package system that are not used anymore and could be cleared, but I don't know if adam want to do that already. I guess you could delete it if it prevents compilation, else it don't hurt to stay there until we kill the whole package tree, or at least until Adam is back. Regards, ~ Simon On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Does anyone know why we have 2 IconRenderers... one in org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major package) and one in package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml; (Faces-major package) I can't tell if the non-Faces-major one is being used anywhere. Can I delete the non-Faces-major one? Thanks, Jeanne
Re: embed key in Icon API - nix it?
I'm going to hold off on this. It seems to be used more than I thought, and it isn't necessary for my work after all. I do think we should get rid of the ALIGN constant, since the html align attribute is deprecated, but this is a clean-up task. - Jeanne Simon Lessard wrote: +1 On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I really doubt that anyone is using the embed property that is in the TextIcon code. The only renderer I see that is using it is the IconRenderer. As part of the work to create span with attributes from the renderer and img/Text with attributes from the skinning definition, I'd like to get rid of the embed property that is in the TextIcon. Any objections? This is a private API right now, which is why I doubt it is being used. - Jeanne Jeanne Waldman wrote: Does anyone know why we have 2 IconRenderers... one in org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major package) and one in package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml; (Faces-major package) I can't tell if the non-Faces-major one is being used anywhere. Can I delete the non-Faces-major one? Thanks, Jeanne
Re: client js objects: prefix with Tr?
I'll comment in email on this. I'm fine with 'tr'. FYI, we voted that for our custom css properties, we are going to use -tri-, in case that influences anyone. -- Jeanne Gabrielle Crawford wrote: Thanks Matthias, Gunther, I have opened an issue for this if anyone wants to comment there: https://issues.apache.org/jira/browse/ADFFACES-168 Thanks, Gabrielle Matthias Wessendorf wrote: On 9/8/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, This isn't the point of this email, but if anyone with committer status is reading this, can you uncomment the link to the client validation chapter here (I'll do it on my next patch otherwise) trinidad\src\site\xdoc\devguide\index.xml done Anyway, Trinidad has some public javascript objects, for example - Converter - Validator - FacesMessage For some doc on these please see: http://incubator.apache.org/adffaces/devguide/clientValidation.html Anyway, I'm thinking these names seem a bit generic and in order to ensure Trin's js names don't clash with the js names of Trin's users I'm wondering if people think it's a good idea to prefix the names with Tr or some other prefix. So for example Maybe Converter/Validator is abit more generic than FacesMessage :) - TrConverter - TrValidator - TrFacesMessage Any votes that this is a good idea? I think it's preferable to use a prefix rather than Trinidad since this does affect the js size. Any preference for the prefix? Any votes for the following or other suggestions? Tr Tri Trin I like the Tr prefix. sounds better than tri or even trin. +1 on Tr Thanks, Gabrielle
adding :hover/:active ability to icons
Hi there, Right now, as I know some of you are aware, you can't create an icon skinning key like this: af|foo::some-icon:hover Since it doesn't end in icon or Icon:alias, the parser will consider it a styleclass. I'd like to add the ability to add :hover and :active to the end of an icon skinning key and keep it an icon. :) (We have a requirement in our 'rich' renderers to change icons on mouse over and on mouse down.) Since we 'pass through' all css-2 pseudo-classes, we pass through :hover and :active to the skinning key. The quick and easy change I was going to make is in the code where I decide if something is an icon or not. Right now I check for if it ends with -icon or Icon:alias. I can change it to check if it ends with -icon - OR - check if it has -icon: in it OR check if it has Icon:alias: in it. Thoughts? - Jeanne
Re: adding :hover/:active ability to icons
I can see your point about ending with 'icon' being confusing, but I
prefer to leave this
alone for now.
I'll go ahead and add support for the :hover/etc on the icon skinning keys.
(I have another issue that goes with this one (new Skin api), but I'll
start a new thread)
- Jeanne
Simon Lessard wrote:
+1 for the idea. However I have some concerns about it.
1) If we were earlier in the skinning design I would have preferred
icon and
aliases to be namespaces, for example:
icon|af|train::stop:visited
alias|SomeName
Ok, the 2 namespaces thing in the first example does not look all that
cool,
but it's easier to standardise that way imho. As for the icon aliases I
would not have treated it in a different way than other aliases. Any
given
icon selector would have included the alias and then after parsing, the
content property value would have been resolved for the icon selector
without needing any special processing. Even better would have been to
use
@namespace but that could mean too much changes to the parser. However it
will be hard to find something cleaner than the following
@namespace rlt {
/* Add some selectors */
@namespace icon {
af|train::stop:visited {
}
}
}
2) The check if it has -icon: might irritates some developers over
time,
they already have many special patterns to learn and adding more means
more
complexity. Also, if this is the solution we choose whenever a need for a
new feature show up, I believe it will look like a bad design in term of
extensibility.
Regards,
~ Simon
On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
Right now, as I know some of you are aware, you can't create an icon
skinning key like this:
af|foo::some-icon:hover
Since it doesn't end in icon or Icon:alias, the parser will consider
it a styleclass.
I'd like to add the ability to add :hover and :active to the end of an
icon skinning key and keep it an icon. :)
(We have a requirement in our 'rich' renderers to change icons on mouse
over and on mouse down.)
Since we 'pass through' all css-2 pseudo-classes, we pass through :hover
and :active to the skinning key.
The quick and easy change I was going to make is in the code where I
decide if something is an icon or not.
Right now I check for if it ends with -icon or Icon:alias.
I can change it to
check if it ends with -icon - OR -
check if it has -icon: in it OR
check if it has Icon:alias: in it.
Thoughts?
- Jeanne
new method on Skin class; new method on Icon class.
Actually, my question is, I need a new method on the Skin class, getIcons().
And in the Icon class, I need a new method, getContent().
This is for our client-side rendering, where we need to pass icon
information to the client.
I need to get all icons that are on the skin, and get the content (img
src... or TextIcon info)
to send to the client.
Also, I'm playing with the idea of generating the img markup in a way
so that
the stuff the renderer specifies goes on a span and the stuff that
comes from the
skinning definition goes on the img. This way we have a cleaner
separation of what
came from the skin and what properties are from the skin's icon definition.
This will come in useful for our client-side rendering, as well. We'd
only need to
pass the icon markup that came from the skin to the client.
Thoughts on this one?
(I'll probably need to add a getProperties() api as well, but one step
at a time)
Thanks!
- Jeanne
Simon Lessard wrote:
I will be all for a new Skin API, let make it an independant module!
On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I can see your point about ending with 'icon' being confusing, but I
prefer to leave this
alone for now.
I'll go ahead and add support for the :hover/etc on the icon skinning
keys.
(I have another issue that goes with this one (new Skin api), but I'll
start a new thread)
- Jeanne
Simon Lessard wrote:
+1 for the idea. However I have some concerns about it.
1) If we were earlier in the skinning design I would have preferred
icon and
aliases to be namespaces, for example:
icon|af|train::stop:visited
alias|SomeName
Ok, the 2 namespaces thing in the first example does not look all that
cool,
but it's easier to standardise that way imho. As for the icon
aliases I
would not have treated it in a different way than other aliases. Any
given
icon selector would have included the alias and then after parsing,
the
content property value would have been resolved for the icon selector
without needing any special processing. Even better would have been to
use
@namespace but that could mean too much changes to the parser. However
it
will be hard to find something cleaner than the following
@namespace rlt {
/* Add some selectors */
@namespace icon {
af|train::stop:visited {
}
}
}
2) The check if it has -icon: might irritates some developers over
time,
they already have many special patterns to learn and adding more means
more
complexity. Also, if this is the solution we choose whenever a need
for
a
new feature show up, I believe it will look like a bad design in
term of
extensibility.
Regards,
~ Simon
On 9/6/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
Right now, as I know some of you are aware, you can't create an icon
skinning key like this:
af|foo::some-icon:hover
Since it doesn't end in icon or Icon:alias, the parser will
consider
it a styleclass.
I'd like to add the ability to add :hover and :active to the end
of an
icon skinning key and keep it an icon. :)
(We have a requirement in our 'rich' renderers to change icons on
mouse
over and on mouse down.)
Since we 'pass through' all css-2 pseudo-classes, we pass through
:hover
and :active to the skinning key.
The quick and easy change I was going to make is in the code where I
decide if something is an icon or not.
Right now I check for if it ends with -icon or Icon:alias.
I can change it to
check if it ends with -icon - OR -
check if it has -icon: in it OR
check if it has Icon:alias: in it.
Thoughts?
- Jeanne
embed key in Icon API - nix it?
I really doubt that anyone is using the embed property that is in the TextIcon code. The only renderer I see that is using it is the IconRenderer. As part of the work to create span with attributes from the renderer and img/Text with attributes from the skinning definition, I'd like to get rid of the embed property that is in the TextIcon. Any objections? This is a private API right now, which is why I doubt it is being used. - Jeanne Jeanne Waldman wrote: Does anyone know why we have 2 IconRenderers... one in org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml; (non Faces-major package) and one in package org.apache.myfaces.trinidadinternal.renderkit.core.xhtml; (Faces-major package) I can't tell if the non-Faces-major one is being used anywhere. Can I delete the non-Faces-major one? Thanks, Jeanne
Re: TrainRenderer using the new train selectors
To: adffaces-dev@incubator.apache.org
Subject: RE: TrainRenderer using the new train selectors
Hello Simon, Jeanne,
I have some comments on both your email exhanges. I have
consolidated all the items below as it was getting hard to
read.
- af|train::stop combinable with :selected, :disabled,
:completed (will probably become p_AFVisited) and :unvisited.
You can append :readOnly at the end of the result. So
af|train::stop:unvisited:readOnly is valid
- Do you think we need to support an
af|train::stop:visited:readOnly
- I believe Jeanne wanted to have states that don't use camel
case. So readOnly should be read-only
- af|train::link
- should this be ::stop-link or ::link good enough?
- af|train::join combinable with :disabled, :completed,
:unvisited and :outer (:outer is used to add joins outside
the edge of the train. I don't think many will use it, but it
cost nothing and add more customization
possibilities)
- :join-outer pseudo element is good enough. Is this used
outside the parent train icons or between the parent train
icons and the overflow (or stop)?
- do we still have the join-overflow? This comes between the
overflow and regular stops. It may be useful in cases where
only these joins need not be displayed.
- af|train::overflow-start combinable with :disabled and
:readOnly
- af|train::overflow-end combinable with :disabled,
:unvisited and :readOnly
- Do you think we should support :unvisited state on
overflow-start? This may be useful in cases where the train
is not sequential? I have a scenario where all stops in the
train are enabled and user can jump around any stop without a
prescribed order.
I have the following valid suffixes: (I could not use
::content for example since double :: is now prevented from
Adam's change to prevent some strange behavior it seem)
-content (for example, the following is valid:
af|train::stop-content and
af|train::stop:selected-content. This selector refers to the
link cell
af|(of the train)
- I agree with Jeanne. Let's call it stop-content:selected. I
don't think we need stop-content:visited or
stop-content:unvisited. It's an overkill.
-icon-block (as above but refers to the icon cell)
- Perhaps we should have a convention of using -block suffix
for style classes that go on div and -cell for styles that
go on td. Is that acceptable?
I use the same join rule as you, that is previous stop
determine the join state, except for the join after the
selected stop. The only exception are disabled stops, those
have disabled joins on both sides.
- the join after the selected stop should ideally have the
state of the following stop. Isn't it? Do you think it will
be easier to just show the left join of a disabled stop as
disabled. So if an unvisited stop follows the disabled
stop, the join between them will show up as unvisited. At
least this is how I have implemented it. I use the same rule
for displaying joins before overflows.
I also go rid of the separator, it's redundant as you can add
padding to -content selector. I also added two aliases
.AFTrainContent:alias and .AFTrainIconBlock. So you can add
spacing between stop with something like the following:
.AFTrainContent:alias
{
padding-left: 8px;
padding-right: 8px;
}
When you say separator, do you mean the spacer that separates
stops? Where is the alias above included? Can you send me a
HTML fragment?
Thanks
- Pavitra
-Original Message-
From: Simon Lessard [mailto: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2006 11:43 AM
To: adffaces-dev@incubator.apache.org
Subject: Re: TrainRenderer using the new train selectors
Ok,
Then if those selectors are ok for you as well Pavitra I'll
make the
changes to -outer and and -icon-cell tonight and upload the
patch as
well as a test skin I used.
Regards,
~ Simon
On 8/29/06, Jeanne Waldman [EMAIL PROTECTED]
wrote:
yep, it all makes sense.
I can see where you'd want to use a ::content. That would
make sense.
We don't do this yet in any of our skinning keys, so I am
fine with
the -content, since we do that all over the place. :)
- Jeanne
Simon Lessard wrote:
Oups, comments below
On 8/29/06, Jeanne Waldman [EMAIL PROTECTED]
wrote:
one question below
Re: Defining styles for access keys (Issue ADFFACES-153)
I'm fine with keeping these private styles for now. We can make them public skinnable keys later if we want to. Yee-Wah Lee wrote: Hi, I'm working on issue ADFFACES-153 and would like to know if people have feedback on the following. Summary of issue AccessKeyUtils decorates the accessKey by printing a HTML element around it. The HTML is passed in by caller Renderer classes, e.g. outputLabel uses U to generate text like UG/Uo to Sitemap. For links, b is used. For labels, u is generated. The proposal is to use CSS instead, e.g. span class=AccessKeyStyleG/spano to Sitemap. What I've done so far: Define global styles to replace b and u, i.e. font-weight: bold, text-decoration:underline. Modify the caller renderer classes to use corresponding style when calling the AccessKeyUtil method. Feedback requested: The 2 new styles are defined in the private section of base-desktop.xss. Should they be made available/moved to a different section? Thanks, Yee-Wah
Re: TrainRenderer using the new train selectors
one question below Simon Lessard wrote: Hello Pavitra, I had to do about the same changes on my side. Here's my list of selector and the rules I used: - af|train::stop combinable with :selected, :disabled, :completed (will probably become p_AFVisited) and :unvisited. You can append :readOnly at the end of the result. So af|train::stop:unvisited:readOnly is valid - af|train::link - af|train::join combinable with :disabled, :completed, :unvisited and :outer (:outer is used to add joins outside the edge of the train. I don't think many will use it, but it cost nothing and add more customization possibilities) Is :outer a state? It sounds to me like it should be af|train::join-outer - af|train::overflow-start combinable with :disabled and :readOnly - af|train::overflow-end combinable with :disabled, :unvisited and :readOnly I have the following valid suffixes: (I could not use ::content for example since double :: is now prevented from Adam's change to prevent some strange behavior it seem) I don't think two pseudo-elements make sense, does it? I suppose you could have a piece of a piece. Adam prevented it because there were bugs in it. I can't recall what the bugs were. -content (for example, the following is valid: af|train::stop-content and af|train::stop:selected-content. This selector refers to the link cell fo the train) What does a :selected-content 'state' mean? How is it different than af|train::stop-content:selected? -icon-block (as above but refers to the icon cell) Could you say -icon-cell? We use 'cell' quite a bit in our skinning selectors. The icons follow the same rule. On 8/28/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote: Hello Simon, I have also almost completed implementing the TrainRenderer using the new skin selectors. It's great to know you are done as well. If you plan to check in the train renderer code anytime soon, can we agree on the common list of skin selectors, so that I can reuse them for my work internally at Oracle? I had to make the following changes and wanted to give you an update. 1. I had to introduce a new state called read-only. This is different from disabled state, like I explained in a previous email. 2. I removed some redundant skin hooks - I can send you the updated list of selectors I am using. I also couldn't get the pass-through states :visited, :active and :unvisited to work, just as you. So I have temporarily defined selectors like Jeanne suggested (using p_AFVisited, p_AFUnvisited etc. and renamed :active to :selected). 3. Finally I have simplified the rules for determining the state of joins. I figured it would be much simpler if we did the following. The join to the left of a stop, is 'always in the same state as the stop' (Overflows could also follow the same rules as stops). So for instance for a train like V - VR - UV - A - D - UVR - V vr uv v d uvrv NOTE: The only exception, is the join to the left of an active stop is visited. Also, UVR and VR are stops that are in 2 states simulataneously - 'visited read-only' and 'unvisited read-only'. Read-only implies the stop cannot be reached (and hence not clickable) and is dictated by the 'readOnly' property on the component commandNavigationItem. Please let me know if the above is ok. Thanks - Pavitra -Original Message- From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 11:43 AM To: adffaces-dev@incubator.apache.org Subject: Re: Train selectors Hmmm you mean somthing like af|train::stop.p_AFVisited? On 8/28/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I was thinking :selected for :active. :selected could be used for other components, too. For :visited/:unvisited, I can't think of a better name. I'm thinking that we should use .p_AFVisited, .P_AFUnvisited until we have the pseudo-class support in. These wouldn't in a public api format, though. - Jeanne [EMAIL PROTECTED] wrote: Hello, I thought about the following name changes for the selectors: :active -- :current or :selected :visited/:unvisited -- :completed/:uncompleted or :seen/:unseen Do you have any other idea/preference? Regards, ~ Simon Simon Lessard [EMAIL PROTECTED] 2006-08-25 22:49 Please respond to adffaces-dev To: Trinidad - Dev adffaces-dev@incubator.apache.org cc: Subject:Train selectors Yes... again... I made a new renderer and it work quite well, but I had to use :ora-visited and :ora-active for some selectors because those are pass through values. Anyone have better name suggestion while we implement state interception on a per component basis? Regards, ~ Simon
Re: TrainRenderer using the new train selectors
yep, it all makes sense. I can see where you'd want to use a ::content. That would make sense. We don't do this yet in any of our skinning keys, so I am fine with the -content, since we do that all over the place. :) - Jeanne Simon Lessard wrote: Oups, comments below On 8/29/06, Jeanne Waldman [EMAIL PROTECTED] wrote: one question below Simon Lessard wrote: Hello Pavitra, I had to do about the same changes on my side. Here's my list of selector and the rules I used: - af|train::stop combinable with :selected, :disabled, :completed (will probably become p_AFVisited) and :unvisited. You can append :readOnly at the end of the result. So af|train::stop:unvisited:readOnly is valid - af|train::link - af|train::join combinable with :disabled, :completed, :unvisited and :outer (:outer is used to add joins outside the edge of the train. I don't think many will use it, but it cost nothing and add more customization possibilities) Is :outer a state? It sounds to me like it should be af|train::join-outer yes, it could be ::join-outer, was made a state only to fit the other join selectors, but it does make more sense to use -outer for that one. Does that make more sense now? Regards, ~ Simon - af|train::overflow-start combinable with :disabled and :readOnly - af|train::overflow-end combinable with :disabled, :unvisited and :readOnly I have the following valid suffixes: (I could not use ::content for example since double :: is now prevented from Adam's change to prevent some strange behavior it seem) I don't think two pseudo-elements make sense, does it? I suppose you could have a piece of a piece. Adam prevented it because there were bugs in it. I can't recall what the bugs were. I was seeing them more as sub-elements, like ::stop::content (content of the stop) -content (for example, the following is valid: af|train::stop-content and af|train::stop:selected-content. This selector refers to the link cell fo the train) What does a :selected-content 'state' mean? How is it different than af|train::stop-content:selected? My bad there, af|train::stop-content:selected is actually what I use. Even if a better selector would have been af|train::stop:selected::content imho. -icon-block (as above but refers to the icon cell) Could you say -icon-cell? We use 'cell' quite a bit in our skinning selectors. Yes I could, I was using block only because it was in Pavitra document at first. The icons follow the same rule. On 8/28/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote: Hello Simon, I have also almost completed implementing the TrainRenderer using the new skin selectors. It's great to know you are done as well. If you plan to check in the train renderer code anytime soon, can we agree on the common list of skin selectors, so that I can reuse them for my work internally at Oracle? I had to make the following changes and wanted to give you an update. 1. I had to introduce a new state called read-only. This is different from disabled state, like I explained in a previous email. 2. I removed some redundant skin hooks - I can send you the updated list of selectors I am using. I also couldn't get the pass-through states :visited, :active and :unvisited to work, just as you. So I have temporarily defined selectors like Jeanne suggested (using p_AFVisited, p_AFUnvisited etc. and renamed :active to :selected). 3. Finally I have simplified the rules for determining the state of joins. I figured it would be much simpler if we did the following. The join to the left of a stop, is 'always in the same state as the stop' (Overflows could also follow the same rules as stops). So for instance for a train like V - VR - UV - A - D - UVR - V vr uv v d uvrv NOTE: The only exception, is the join to the left of an active stop is visited. Also, UVR and VR are stops that are in 2 states simulataneously - 'visited read-only' and 'unvisited read-only'. Read-only implies the stop cannot be reached (and hence not clickable) and is dictated by the 'readOnly' property on the component commandNavigationItem. Please let me know if the above is ok. Thanks - Pavitra -Original Message- From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 11:43 AM To: adffaces-dev@incubator.apache.org Subject: Re: Train selectors Hmmm you mean somthing like af|train::stop.p_AFVisited? On 8/28/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I was thinking :selected for :active. :selected could be used for other components, too. For :visited/:unvisited, I can't think of a better name. I'm thinking that we should use .p_AFVisited, .P_AFUnvisited until we have the pseudo-class support in. These wouldn't in a public api format, though. - Jeanne [EMAIL PROTECTED] wrote: Hello, I thought
Re: TrainRenderer using the new train selectors
Sounds good to me. Simon Lessard wrote: Ok, Then if those selectors are ok for you as well Pavitra I'll make the changes to -outer and and -icon-cell tonight and upload the patch as well as a test skin I used. Regards, ~ Simon On 8/29/06, Jeanne Waldman [EMAIL PROTECTED] wrote: yep, it all makes sense. I can see where you'd want to use a ::content. That would make sense. We don't do this yet in any of our skinning keys, so I am fine with the -content, since we do that all over the place. :) - Jeanne Simon Lessard wrote: Oups, comments below On 8/29/06, Jeanne Waldman [EMAIL PROTECTED] wrote: one question below Simon Lessard wrote: Hello Pavitra, I had to do about the same changes on my side. Here's my list of selector and the rules I used: - af|train::stop combinable with :selected, :disabled, :completed (will probably become p_AFVisited) and :unvisited. You can append :readOnly at the end of the result. So af|train::stop:unvisited:readOnly is valid - af|train::link - af|train::join combinable with :disabled, :completed, :unvisited and :outer (:outer is used to add joins outside the edge of the train. I don't think many will use it, but it cost nothing and add more customization possibilities) Is :outer a state? It sounds to me like it should be af|train::join-outer yes, it could be ::join-outer, was made a state only to fit the other join selectors, but it does make more sense to use -outer for that one. Does that make more sense now? Regards, ~ Simon - af|train::overflow-start combinable with :disabled and :readOnly - af|train::overflow-end combinable with :disabled, :unvisited and :readOnly I have the following valid suffixes: (I could not use ::content for example since double :: is now prevented from Adam's change to prevent some strange behavior it seem) I don't think two pseudo-elements make sense, does it? I suppose you could have a piece of a piece. Adam prevented it because there were bugs in it. I can't recall what the bugs were. I was seeing them more as sub-elements, like ::stop::content (content of the stop) -content (for example, the following is valid: af|train::stop-content and af|train::stop:selected-content. This selector refers to the link cell fo the train) What does a :selected-content 'state' mean? How is it different than af|train::stop-content:selected? My bad there, af|train::stop-content:selected is actually what I use. Even if a better selector would have been af|train::stop:selected::content imho. -icon-block (as above but refers to the icon cell) Could you say -icon-cell? We use 'cell' quite a bit in our skinning selectors. Yes I could, I was using block only because it was in Pavitra document at first. The icons follow the same rule. On 8/28/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote: Hello Simon, I have also almost completed implementing the TrainRenderer using the new skin selectors. It's great to know you are done as well. If you plan to check in the train renderer code anytime soon, can we agree on the common list of skin selectors, so that I can reuse them for my work internally at Oracle? I had to make the following changes and wanted to give you an update. 1. I had to introduce a new state called read-only. This is different from disabled state, like I explained in a previous email. 2. I removed some redundant skin hooks - I can send you the updated list of selectors I am using. I also couldn't get the pass-through states :visited, :active and :unvisited to work, just as you. So I have temporarily defined selectors like Jeanne suggested (using p_AFVisited, p_AFUnvisited etc. and renamed :active to :selected). 3. Finally I have simplified the rules for determining the state of joins. I figured it would be much simpler if we did the following. The join to the left of a stop, is 'always in the same state as the stop' (Overflows could also follow the same rules as stops). So for instance for a train like V - VR - UV - A - D - UVR - V vr uv v d uvrv NOTE: The only exception, is the join to the left of an active stop is visited. Also, UVR and VR are stops that are in 2 states simulataneously - 'visited read-only' and 'unvisited read-only'. Read-only implies the stop cannot be reached (and hence not clickable) and is dictated by the 'readOnly' property on the component commandNavigationItem. Please let me know if the above is ok. Thanks - Pavitra -Original Message- From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 11:43 AM To: adffaces-dev@incubator.apache.org Subject: Re: Train selectors Hmmm you mean somthing like af|train::stop.p_AFVisited? On 8/28/06, Jeanne Waldman [EMAIL
Re: TrainRenderer using the new train selectors
We don't want to expose the html, that is for sure. So using block for divs and cell for tds should be out. I was just saying that the skin selector keys we use in Trinidad use cell or content, but not block, so even though we weren't as consistent as we should have been, let's not add to the inconsistency by adding a new term. :) Pavitra Subramaniam wrote: Yes it does. That's why I used -block everywhere and some other places -content. But Jeanne seems to recommend cell, so not sure. !-- Converted from text/rtf format -- - Pavitra From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 2:00 PM To: adffaces-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: TrainRenderer using the new train selectors Ah, don't that expose the markup though? ~ Simon On 8/29/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote: I am using block to indicate style class that goes in a div and technically I should use cell for style class that goes in a td - Pavitra -Original Message- From: Simon Lessard [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 11:18 AM To: adffaces-dev@incubator.apache.org Subject: Re: TrainRenderer using the new train selectors Oups, comments below On 8/29/06, Jeanne Waldman [EMAIL PROTECTED] wrote: one question below Simon Lessard wrote: Hello Pavitra,I had to do about the same changes on my side. Here's my list of selectorand the rules I used: - af|train::stop combinable with :selected, :disabled, :completed (will probably become p_AFVisited) and :unvisited. You can append:readOnly at the end of the result. Soaf|train::stop:unvisited:readOnly is valid- af|train::link - af|train::join combinable with :disabled, :completed, :unvisitedand :outer (:outer is used to add joins outside the edge of thetrain. I don't think many will use it, but it cost nothing and addmore customizationpossibilities) Is :outer a state? It sounds to me like it should be af|train::join-outer yes, it could be ::join-outer, was made a state only to fit the other join selectors, but it does make more sense to use -outer for that one.Does that make more sense now? Regards, ~ Simon- af|train::overflow-start combinable with :disabled and :readOnly- af|train::overflow-end combinable with :disabled, :unvisited and :readOnly I have the following valid suffixes: (I could not use ::content forexample since double :: is now prevented from Adam's change to prevent some strange behavior it seem) I don't think two pseudo-elements make sense, does it? I suppose you could have a piece of a piece. Adam prevented it because there werebugs in it. I can't recall what the bugs were.I was seeing them more as sub-elements, like ::stop::content (content of the stop)-content(for example, the following is valid: af|train::stop-contentandaf|train::stop:selected-content. This selector refers to the linkaf|cell fothe train) What does a :selected-content 'state' mean? How is it different than af|train::stop-content:selected?My bad there, af|train::stop-content:selected is actually what I use. Even if a better selector would have been af|train::stop:selected::content imho.-icon-block (as above but refers to the icon cell) Could you say -icon-cell? We use 'cell' quite a bit in our skinning selectors. Yes I could, I was using block only because it was in Pavitra document at first. The icons follow the same rule. On 8/28/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote: Hello Simon, I have also almost completed implementing the TrainRenderer usingthe new skin selectors. It's great to know you are done as well. Ifyou plan to check in the train renderer code anytime soon, can we agree on the common list of skin selectors, so that I can reusethem for my work internally at Oracle? I had to make the followingchanges and wanted to give you an update.1. I had to introduce a new state called read-only. This isdifferent from disabled state, like I explained in a previous email.2. I removed some redundant skin hooks - I can send you the updated listof selectors I am using. I also couldn't get the pass-through states :visited, :active and :unvisited to work, just as you. So I havetemporarily defined selectors like Jeanne suggested (usingp_AFVisited, p_AFUnvisited etc. and renamed :active to :selected). 3. Finally I have simplified the rules for determining the state ofjoins.I figured it would be much simpler if we did the following. The join to the left of a stop, is 'always in the same state as thestop' (Overflows could also follow the same rules as stops). So forinstance for a train likeV - VR - UV - A - D - UVR - Vvr uv v duvrv NOTE: The only
Re: Custom Skins for Different Form Factors
a couple comments inline... Joseph Rozier wrote: Hi, Jeanne, I've got some comments inline... On 8/23/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi Joey, We have simple-desktop and simple-pda skins. You can create a pda or desktop skin by specifying the render-kit-id in your skin. The pda skin extends simple-pda skin. The desktop skin extends simple-desktop. You created a plus-desktop skin that extends simple-desktop skin. You like that skin a lot and it has a lot of definitions. Now you need a pda version. You want to use the plus-desktop skin, but you want it to extend simple-pda instead. Well, if I create a skin in trinidad-skins.xml for the pda renderkit but use the same plus-desktop.css file I use for the desktop renderkit, then it extends simple-pda. The problem is that the plus-desktop.css file might have overwritten some of the PDA specific properties from simple-pda. For example, simple-pda.xss specifies AFDefaultFont as font-size: 9px, but plus-desktop specifies AFDefaultFont as font-size: 11px. If you make your plus-pda skin extend plus-desktop skin, it will go through simple-desktop. (you've verified this, right?) I didn't think it was possible for one skin to extend another in that way--I thought they could only extend from simple-pda/simple-desktop currently. Is that not the case? This was the way it used to be a long time ago. Go ahead and try it. What I have tried is what I described above (creating the skin declaratively in trinidad-skins.xml for the PDA RenderKit), and in that case the skin extended simple-pda, not simple-desktop. You don't want that. You want your plus-pda skin to extend plus-desktop skin, but then you want that to go through simple-pda instead of simple-desktop. It's not just that I want it to use simple-pda. Say I have my plus-desktop.css extending from simple-pda. Now, my plus-desktop.css defines an AFDefaultFont size (geared towards replacing the AFDefaultFont size specified in simple-desktop), so that overwrites the AFDefaultFont size that I specified in simple-pda. To fix this, I'd like to have either: 1) a way to overwrite this AFDefaultFontSize in a plus-pda.css that extends plus-desktop.css OR 2) a plus-generic.css that doesn't specify an AFDefaultFontSize (but specifies all style info that is common to pdadesktop) and then plus-desktop.css and plus-pda.css that specifies only those features that each needs to def I've thought about this some and I think we need a concept of a render-kit-neutral skin. This skin, if picked, will default to extend simple-desktop. But if this skin is used as a base skin for plus-pda, it will eventually extend from simple-pda (the simple skin with the same render-kit-it). Another option is to allow imports in the skinning .css file. So you can import the stylesheet definitions. We have this feature in XSS, which is why you see simple-pda.xss imports simple-desktop.xss. I like the 'abstract' skin idea better. Resource bundles aren't a part of the css file, and you might want to inherit those, too. These are interesting ideas. Would it be possible to have both? :) I'm thinking now that since .xss has imports, the code is probably there to allow the skinning .css file to have imports pretty easily as well. I'd go this route first, before I'd do the abstract skin idea. I don't know how hard/easy it is to implement these ideas. One question, how much will need to change if you forget extending simple-pda, and have your plus-pda skin extend plus-desktop which extends simple-desktop? If it is just a few fonts, then it might easy enough to go that route until we have something in place. I haven't looked into this in detail, but my gut tells me that plus-pda will likely contain much of what simple-pda contains (as an attempt to overwrite the properties set in plus-desktop). If there is a way for a plus-pda to extend plus-desktop which extends simple-desktop (or simple-pda), then that would likely give me what I need for now. Joseph Rozier wrote: Hello, The current method of skin inheritance leads to some issues when a developer wishes to create a skin family targetting desktop and PDA. There's no way to make a large number of changes that affect both desktop and pda in one place, and then tweak what needs to be tweaked for desktop or PDA. For example, I may want to change the color in both desktop and PDA, but I might want to change the font size to 20 for the desktop and 6 for the PDA. The reason for the problem is that each skin can only extend Trinidad's simple skin. There is no way to have an abstract plus skin that makes the common changes, and then have a plus-desktop skin and plus-pda skin that makes desktop/pda specific changes. (Also note that today things are a bit odder, because there's a simple-pda.xss that extends simple-desktop.xss. If I specify a skin in trinidad-skins.xml that is for use with the desktop RenderKit, its css inherits from
Re: RTL question
Hi Simon, Appending :rtl should work. There's a chance that this broke recently. I'll have to double check. I'll make this high priority. - Jeanne Simon Lessard wrote: Hello all, Can anyone give me a really short course about RTL support we have in Trinidad? Basically, I thought I had to add :rtl to style classes within the renderer and the skin, but that's obviously not the case, :rtl to selectors seems to work only on icons. In the XSS it's 2 different stylesheets, but how does it work with CSS skins? Currently I was able to have it work by adding p_AFRtl to generated elements' style classes but that must not be the best way to acheive it. Regards, ~ Simon
Re: ADFFACES-49 inputText::content:required or inputText:required::content
My opinion is that if you want the same pseudo-class to pass through
when in one state and not when in the other state, then I would just not
have it pass through in either case, and handle it yourself.
- Jeanne
Simon Lessard wrote:
Hello Pavitra,
My solution would work with it as it is binary, the pseudo-class
either get
intercepted or pass through, independently of the enclosing element. For
:hover case, it would always go through for Firefox, except if the
component
said he wanted to intercept that pseudo-class and for IE it would
always get
intercepted, even on a / element since the JavaScript required to
emulate
a pseudo-class should always be the same, independently of the element.
So in your case, it would not work. However, I wonder why you would
want to
intercept it in a case and not in the other as it only remove flexibility
for the end user imho. Can you explain the reason a bit more please?
Regards,
~ Simon
On 8/23/06, Pavitra Subramaniam [EMAIL PROTECTED] wrote:
Hello Jeanne and Simon,
There could be cases where intercepted states for a component or it's
sub-part need to be considered together rather than individually. Or
in some
case it might be too early for even the renderer to provide a valid
interceptor-state list at init time. The best time may be at
rendering time.
For instance, let's assume that the component sub-part af|train::stop
can be in the following states :visited and :selected states.
At runtime if the stop is selected, it may be rendered as a span and
as an
anchor, a , if it was visited before (and hence clickable). Both these
elements may want to support the :hover pseudo-class.
If I wanted the :hover to pass through if it's for selected stop (for
the
span) and intercept :hover if it's for a stop that is visited (link),
would the proposed solution work?
Thanks
- Pavitra
-Original Message-
From: Simon Lessard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 6:28 AM
To: adffaces-dev@incubator.apache.org
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
Hello Jeanne,
Yes I'm aware that states can go on the component's sub-part, but are
you
suggesting that we extends the concept to be flexible enough to allow
thecomponent to intercept a given state on the root element but not
on the
sub-part? e.g. inputText would intercept :disabled when placed on
af|inputText but not on af|inputText::content? That's some complexity
af|but
it's doable I guess.
Regards,
~Simon
On 8/22/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree that only the renderers should know what states they want to
intercept. I was thinking we add this information in the renderer .xml
file and then when we build our classes, we can put this information
somewhere -- not sure where.
I'm sure you realize this, but just in case... the states do not have
to go on the root dom element, they can go on sub-root elements, like
af|train::stop:disabled.
Simon Lessard wrote:
Hmmm, I'm leaning toward the per component basis option more and
more.
However, I hate static lists and additional config files are not all
that
great. I see a possibility though. Maybe it will work, but I did not
explore that area much yet so I might say something stupid.
Currently it seem to me that skins are linked to the renderkit. So,
how feasible would it be to create a SkinRenderKitFactory that
would, before giving away any renderer, would populate a
Mapcomponent, liststate be interrogating all renderers in the
kit. That way, when StyleSheetRenderer would do its work, we would
be sure that the list is populated. Also, with that solution, only
the renderers would have to know what states they want to intercept.
This also fix the synchronization issue, changing the kit or the
renderer would automatically update the interception list. We would
have to create a
new
BaseRenderer in the API however. I see two additional methods needed
for such renderers:
public String getComponentName() // or I guess getRootStyleClass
would work just as well public ListString getInterceptedStates();
// Returning the list of states to intercept.
Makes sense?
~ Simon
On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
More comments inline.
Which way are you leaning?
- Jeanne
Simon Lessard wrote:
Hello Jeanne,
Thanks for the complete answer.
On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi Simon,
Thanks for the email.
[EMAIL PROTECTED] wrote:
We use both syntaxes, and they mean different things.
For example:
af|train::stop:disabled (when this train's stop is disabled,
af|then
style
the stop like this)
af|train:disabled::stop (when the entire train is disabled,
style all
the stops like this)
Agreed.
Let's say I have this: span class=myTextHello!/span and
this
css:
.myText {color
Re: RTL question
I tried this and it works for me. There is a demo of it in the purple
skin's css file.
af|inputText::content:rtl
{
color: red;
}
If you set the browser to be a rtl language and run the inputText demo,
you'll see the content's text is red.
- Jeanne
Jeanne Waldman wrote:
Hi Simon,
Appending :rtl should work. There's a chance that this broke recently.
I'll have to double check. I'll make this high priority.
- Jeanne
Simon Lessard wrote:
Hello all,
Can anyone give me a really short course about RTL support we have in
Trinidad? Basically, I thought I had to add :rtl to style classes
within the
renderer and the skin, but that's obviously not the case, :rtl to
selectors
seems to work only on icons. In the XSS it's 2 different stylesheets,
but
how does it work with CSS skins?
Currently I was able to have it work by adding p_AFRtl to generated
elements' style classes but that must not be the best way to acheive it.
Regards,
~ Simon
Re: ADFFACES-49 inputText::content:required or inputText:required::content
I wasn't really suggesting anything.
By the way, in case you didn't notice, Adam made a change yesterday so
that ALL pseudo-classes get transformed to .p_AF*, except for the css-2
pseudo-classes, which pass through.
This simple change buys us a lot. It satisfies my immediate need for a
pseudo-class solution, and it heads us in the right direction, in that
the pseudo-class api doesn't have to change when we implement the full
solution that gives the component developer's more flexibility.
Thanks, Adam!
- Jeanne
Simon Lessard wrote:
Hello Jeanne,
Yes I'm aware that states can go on the component's sub-part, but are you
suggesting that we extends the concept to be flexible enough to allow
thecomponent to intercept a given state on the root element but not on
the
sub-part? e.g. inputText would intercept :disabled when placed on
af|inputText but not on af|inputText::content? That's some complexity but
it's doable I guess.
Regards,
~Simon
On 8/22/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I agree that only the renderers should know what states they want to
intercept. I was thinking we add this information in the renderer .xml
file and then when we build our classes, we can put this information
somewhere -- not sure where.
I'm sure you realize this, but just in case... the states do not have to
go on the root dom element, they can go on sub-root elements, like
af|train::stop:disabled.
Simon Lessard wrote:
Hmmm, I'm leaning toward the per component basis option more and more.
However, I hate static lists and additional config files are not all
that
great. I see a possibility though. Maybe it will work, but I did not
explore
that area much yet so I might say something stupid. Currently it seem
to me
that skins are linked to the renderkit. So, how feasible would it
be to
create a SkinRenderKitFactory that would, before giving away any
renderer,
would populate a Mapcomponent, liststate be interrogating all
renderers
in the kit. That way, when StyleSheetRenderer would do its work, we
would be
sure that the list is populated. Also, with that solution, only the
renderers would have to know what states they want to intercept. This
also
fix the synchronization issue, changing the kit or the renderer would
automatically update the interception list. We would have to create a
new
BaseRenderer in the API however. I see two additional methods
needed for
such renderers:
public String getComponentName() // or I guess getRootStyleClass would
work
just as well
public ListString getInterceptedStates(); // Returning the list of
states
to intercept.
Makes sense?
~ Simon
On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
More comments inline.
Which way are you leaning?
- Jeanne
Simon Lessard wrote:
Hello Jeanne,
Thanks for the complete answer.
On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi Simon,
Thanks for the email.
[EMAIL PROTECTED] wrote:
We use both syntaxes, and they mean different things.
For example:
af|train::stop:disabled (when this train's stop is disabled,
then
style
the stop like this)
af|train:disabled::stop (when the entire train is disabled,
style all
the stops like this)
Agreed.
Let's say I have this: span class=myTextHello!/span and
this
css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover
should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like
:disabled),
we
resolve it there and it never pass through so we prevent all bad
support
from the browser. For states that cannot be resolved in Java, we
could
ask
the Agent if it supports the specified pseudo-class for the
generated
element (link:hover works in IE, but not on anything else). If
the
agent
supports it, we let the class pass through to the generated CSS
file, if
the agent does not, then we could add some JS code to emulate it.
We generate the css file before we render the components, so when
you
say we should intercept all pseudo-classes and if it can be
resolved on
the Java side, we should resolve it. But how would we know at this
point
where we are going to render the pseudo-class? that af|foo:hover
will
be
generated on a link? Maybe af|foo:hover is on a span, but
af|foo::step:hover is on the link. (we would know if we kept the
skinning-key - pseudo-class to resolve map). Or do you mean
literally
that if we can resolve it on the Java side -- even if the browser
can
as
well -- we go ahead and do that?
I mean litterally that we make a list of pseudo-classes that we
know
we can
always resolve during rendering, like :disabled, and always
intercept
it. In
a sense it would be a way
Re: Custom Skins for Different Form Factors
Hi Joey, We have simple-desktop and simple-pda skins. You can create a pda or desktop skin by specifying the render-kit-id in your skin. The pda skin extends simple-pda skin. The desktop skin extends simple-desktop. You created a plus-desktop skin that extends simple-desktop skin. You like that skin a lot and it has a lot of definitions. Now you need a pda version. You want to use the plus-desktop skin, but you want it to extend simple-pda instead. If you make your plus-pda skin extend plus-desktop skin, it will go through simple-desktop. (you've verified this, right?) You don't want that. You want your plus-pda skin to extend plus-desktop skin, but then you want that to go through simple-pda instead of simple-desktop. I've thought about this some and I think we need a concept of a render-kit-neutral skin. This skin, if picked, will default to extend simple-desktop. But if this skin is used as a base skin for plus-pda, it will eventually extend from simple-pda (the simple skin with the same render-kit-it). Another option is to allow imports in the skinning .css file. So you can import the stylesheet definitions. We have this feature in XSS, which is why you see simple-pda.xss imports simple-desktop.xss. I like the 'abstract' skin idea better. Resource bundles aren't a part of the css file, and you might want to inherit those, too. I don't know how hard/easy it is to implement these ideas. One question, how much will need to change if you forget extending simple-pda, and have your plus-pda skin extend plus-desktop which extends simple-desktop? If it is just a few fonts, then it might easy enough to go that route until we have something in place. Joseph Rozier wrote: Hello, The current method of skin inheritance leads to some issues when a developer wishes to create a skin family targetting desktop and PDA. There's no way to make a large number of changes that affect both desktop and pda in one place, and then tweak what needs to be tweaked for desktop or PDA. For example, I may want to change the color in both desktop and PDA, but I might want to change the font size to 20 for the desktop and 6 for the PDA. The reason for the problem is that each skin can only extend Trinidad's simple skin. There is no way to have an abstract plus skin that makes the common changes, and then have a plus-desktop skin and plus-pda skin that makes desktop/pda specific changes. (Also note that today things are a bit odder, because there's a simple-pda.xss that extends simple-desktop.xss. If I specify a skin in trinidad-skins.xml that is for use with the desktop RenderKit, its css inherits from simple-desktop.xss. If I instead specify its use for the pda RenderKit, its css inherits from simple-pda.xss. However, this doesn't lead to a solution because my plus.css may override a font that is specified in simple-desktop.xss or simple-pda.xss, so that font would now be used on both desktop and pda.) I'm hoping that the skinning experts can provide insights/solutions to this problem. Thanks, Joey
Re: [Issue] AFEndPadding appears twice in base-desktop.xss
This is wanted. The second one is in a different stylesheet: styleSheet direction=rtl - Jeanne Simon Lessard wrote: Hello all, Is that wanted? ~ Simon
Re: panelBox image borders desupport
Please use start instead of left and end instead of right.
This way it still makes sense in rtl languages.
See this link for selector names for inspiration:
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/skin-selectors.html
- Jeanne
Adam Winer wrote:
+1 to this; and put an af|panelBox on the top table, 'course.
-- Adam
On 8/22/06, Simon Lessard [EMAIL PROTECTED] wrote:
Hello everyones,
I see that image borders around panelBox are no longer possible, is
there a
reason for this or it was simply forgotten while switching to faces
major
renderer? If that was an image package issue, I think we can re-add the
support without calling that API simply by generating something like
table
tr
td class=af|panelBox::top-left-corner/
td class=af|panelBox::top/
td class=af|panelBox::top-right-corner/
/tr
tr
td class=af|panelBox::left/
td class=af|panelBox::content
!-- Box content --
/td
td class=af|panelBox::right/
/tr
tr
td class=af|panelBox::bottom-left-corner/
td class=af|panelBox::bottom/
td class=af|panelBox::bottom-right-corner/
/tr
/table
with style classes looking like:
af|panelBox::top
{
background-image: url(...);
background-repeat: repeat-x;
}
af|panelBox::left
{
background-image: url(...);
background-repeat: repeat-y;
}
af|panelBox::bottom
{
background-image: url(...);
background-repeat: repeat-x;
}
af|panelBox::right
{
background-image: url(...);
background-repeat: repeat-y;
}
af|panelBox::top-left-corner
{
background-image: url(...);
height: imageHeight;
width: imageWidth;
}
af|panelBox::top-right-corner
{
background-image: url(...);
height: imageHeight;
width: imageWidth;
}
af|panelBox::bottom-left-corner
{
background-image: url(...);
height: imageHeight;
width: imageWidth;
}
af|panelBox::bottom-right-corner
{
background-image: url(...);
height: imageHeight;
width: imageWidth;
}
af|panelBox::content
{
background-color: rgb(...);
}
Is there anything I don't see? That would prevent it from working?
Re: ADFFACES-49 inputText::content:required or inputText:required::content
Hi Simon,
Thanks for the email.
[EMAIL PROTECTED] wrote:
We use both syntaxes, and they mean different things.
For example:
af|train::stop:disabled (when this train's stop is disabled, then style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
Agreed.
Let's say I have this: span class=myTextHello!/span and this css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like :disabled), we
resolve it there and it never pass through so we prevent all bad support
from the browser. For states that cannot be resolved in Java, we could ask
the Agent if it supports the specified pseudo-class for the generated
element (link:hover works in IE, but not on anything else). If the agent
supports it, we let the class pass through to the generated CSS file, if
the agent does not, then we could add some JS code to emulate it.
We generate the css file before we render the components, so when you
say we should intercept all pseudo-classes and if it can be resolved on
the Java side, we should resolve it. But how would we know at this point
where we are going to render the pseudo-class? that af|foo:hover will be
generated on a link? Maybe af|foo:hover is on a span, but
af|foo::step:hover is on the link. (we would know if we kept the
skinning-key - pseudo-class to resolve map). Or do you mean literally
that if we can resolve it on the Java side -- even if the browser can as
well -- we go ahead and do that?
In the case of :hover, do we pass that through for IE or not? Let's say
we don't pass it through for IE. Then we'll need some code that gets
:hover and says, oh, we are on IE, so don't pass this through but
instead do some onmouseover + css magic. This seems like it could get
messy fast.
The main problem I have the per component option is the potential
performance overhaul it represents as well as the increased component
development complexity (since you have to put more information in the
metadata).
I don't think of this as a performance hit, since this will happen at
the css generation time, not with every renderer. And we cache the
generated css file.
It would be like the map I have now in FileSystemStyleCache.
However, we would need to keep the renderer and this map in sync. For my
renderer 'foo', I know that I want to handle 'hover' myself, so I put
the hover - p_AFHover in the map that will be consulted when we
generate the css file. af|foo:hover does not pass through. All other
:hover passes through. I don't think this is that terrible. I like this
better than the prefix, because if, down the line, we decide that we can
pass through the pseudo-class, the user's skin will not have to change,
but our code will get simpler.
The prefix is ok, but I find it a bit counter intuitive since the user has
to know which states will be handled by browser and which are managed by
Trinidad. I would prefer to hide that kind of low level implementation
details to skinners.
We would definitely document all the -tri- pseudo-classes per skinning
key. For example:
af|inputText:-tri-required, af|inputText:-tri-read-only,
af|inputText:-tri-disabled. But for af|train::stop-link,
we'd document that they can use :hover.
On a side note that could lead to a new post, what should we do with
icons? Currently the engine considers a selector an icon one if it ends
with -icon. This lead to some strange selectors sometimes like
-icon-style-class simply to prevent the parser to interpret it as an icon.
Maybe we should add something like :::icon, ::tri-icon or --icon? That way
there will be no ambiguity left.
I don't have a problem with saying -icon-style when what you mean is
that you want to style the icon, and ending the key with -icon when it
means an icon.
- Jeanne
Regards
¬ Simon
Jeanne Waldman [EMAIL PROTECTED]
2006-08-18 18:27
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: ADFFACES-49 inputText::content:required or
inputText:required::content
see inline for some random thoughts. :) I'm glad you brought this up,
because I need to come up with a solution soon for our internal project
that we are working on so that our developers can write their renderers
correctly.
[EMAIL PROTECTED] wrote:
Hello all,
I raised that issue a while back, but now it's a bit more important since
I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
prefer for states:
1.1. component::subPart:state
1.2. component:state::subPart.
We use both syntaxes, and they mean different things.
1.1 means
Re: ADFFACES-49 inputText::content:required or inputText:required::content
More comments inline.
Which way are you leaning?
- Jeanne
Simon Lessard wrote:
Hello Jeanne,
Thanks for the complete answer.
On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi Simon,
Thanks for the email.
[EMAIL PROTECTED] wrote:
We use both syntaxes, and they mean different things.
For example:
af|train::stop:disabled (when this train's stop is disabled, then
style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
Agreed.
Let's say I have this: span class=myTextHello!/span and this
css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like :disabled), we
resolve it there and it never pass through so we prevent all bad
support
from the browser. For states that cannot be resolved in Java, we could
ask
the Agent if it supports the specified pseudo-class for the generated
element (link:hover works in IE, but not on anything else). If the
agent
supports it, we let the class pass through to the generated CSS
file, if
the agent does not, then we could add some JS code to emulate it.
We generate the css file before we render the components, so when you
say we should intercept all pseudo-classes and if it can be resolved on
the Java side, we should resolve it. But how would we know at this point
where we are going to render the pseudo-class? that af|foo:hover will be
generated on a link? Maybe af|foo:hover is on a span, but
af|foo::step:hover is on the link. (we would know if we kept the
skinning-key - pseudo-class to resolve map). Or do you mean literally
that if we can resolve it on the Java side -- even if the browser can as
well -- we go ahead and do that?
I mean litterally that we make a list of pseudo-classes that we know
we can
always resolve during rendering, like :disabled, and always intercept
it. In
a sense it would be a way to cover browsers' lack of support for those
pseudo-classes.
In the case of :hover, do we pass that through for IE or not? Let's say
we don't pass it through for IE. Then we'll need some code that gets
:hover and says, oh, we are on IE, so don't pass this through but
instead do some onmouseover + css magic. This seems like it could get
messy fast.
Fair point, the renderers would have to check if there's a selector using
:hover defined in the current skin and add some JS, it's messy indeed.
The main problem I have the per component option is the potential
performance overhaul it represents as well as the increased component
development complexity (since you have to put more information in the
metadata).
I don't think of this as a performance hit, since this will happen at
the css generation time, not with every renderer. And we cache the
generated css file.
It would be like the map I have now in FileSystemStyleCache.
Small question here. When is the CSS generated exactly? Is it at
startup or
at the first request for a given skin family? If it is during startup,
the
performance hit is indeed a non issue.
rendered in StyleSheetRenderer. We get it out of the cache if it is
there, otherwise we generate it.
However, we would need to keep the renderer and this map in sync. For my
renderer 'foo', I know that I want to handle 'hover' myself, so I put
the hover - p_AFHover in the map that will be consulted when we
generate the css file. af|foo:hover does not pass through. All other
:hover passes through. I don't think this is that terrible. I like this
better than the prefix, because if, down the line, we decide that we can
pass through the pseudo-class, the user's skin will not have to change,
but our code will get simpler.
Not that bad, but I kind of dislike hard coded lists as component
developers
won't be able to use the skinning feature without giving it to Trinidad
project since they will have to hack Trinidad's jar file to add their own
states to the map. If that way is chosen, I would rather use another
configuration file or some faces-config meta-data entries. For now
skin is
not a public API, but I'm prety sure it will become one at some point in
time.
We definitely need to get it out of FileSystemStyleCache. No doubt about it.
The prefix is ok, but I find it a bit counter intuitive since the
user has
to know which states will be handled by browser and which are
managed by
Trinidad. I would prefer to hide that kind of low level implementation
details to skinners.
We would definitely document all the -tri- pseudo-classes per skinning
key. For example:
af|inputText:-tri-required, af|inputText:-tri-read-only,
af|inputText:-tri-disabled. But for af|train::stop-link,
we'd document that they can use :hover.
It works, but it's a bit ugly imho
Re: [Proposal] Change to RenderingContext.setSkinResourceKeyMap semantic
Hi Simon, This pattern was introduced to handle the case where we are using the same renderer to render different components, but we want to make sure the style classes that get rendered are for the correct component. If I'm writing a renderer for the XYZ component, and I want to use the menuBar renderer code, then I would map the menuBar style classes to XYZ style classes. That way I'll get XYZ style classes for my XYZ component. If a renderer doesn't share rendering code, then they don't need to do this. Another thing the renderer could do is to use renderer delegation. Then, the renderer could have a inner class that overrides the MenuBar renderer, for example, and overrides the methods which return style classes (this assumes there are appropriate hooks for this in the renderer you are overriding, which probably isn't the case) I don't understand your grandparent example well enough to comment on it. First I wanted to be sure you understand what the purpose of this map is. - Jeanne Simon Lessard wrote: Hello all, It seems that most renderers use RenderingContext.setSkinResourceKeyMap to temporarily alter the skin selectors used by their children. The use case is almost always : Map original = RenderingContext.getSkinResourceKeyMap(); RenderingContext.setSkinResourceKeyMap(newMap); // do some work RenderingContext.setSkinResourceKeyMap(original); I see three problems with that pattern. First, there's no way to enforce it. Secondly, it can lead to some unworking case. Imagine we have something like: grand-parent parent child/ /parent /grand-parent Now let say child uses af|component, af|component::part and af|component::part:state selectors. Let assume that grand-parent redirects af|component to GrandParentReplacement and parent redirects af|component::part to ParentReplacement and af|component::part:state to af|component. The above pattern will result in the following redirections: - af|component -- not redirected - af|component::part -- ParentReplacement - af|component::part:state -- af|component However, the above result is most likely not what was wanted. I believe it should be more like: - af|component -- GrandParentReplacement - af|component::part -- ParentReplacement - af|component::part:state -- GrandParentReplacement So I would suggest to change setSkinResourceKeyMap to pushSkinResourceKeyMap and add a popSkinResourceKeyMap as well as a peekSkinResourceKeyMap. The selector resolution could then move through the whole redirection chain as well as simplify the code required inside renderer. The above code would become: RenderingContext.pushSkinResourceKeyMap(newMap); // do some work RenderingContext.popSkinResourceKeyMap(); The third problem I see with this pattern is that parents has to know what kind of children they will contain, which is really bad for the component developers working outside Trinidad project but wanting to use its internal feature (yes I know, that API is not currently public). I don't see any solution to this problem yet, but I believe we should find a standardized way to handle children selector redirection because some Trinidad components seem a bit too strongly coupled together imho. Regards, ~ Simon
Re: [Proposal] Change to RenderingContext.setSkinResourceKeyMap semantic
This is probably true. The person that is writing the renderer and knowing that he is sharing the menuBar renderer can look at the menuBar renderer to see that it is mapping to somethingOriginalKey, and then he would map somethingOriginalKey to af|XYZ::something. This isn't ideal, I agree, but I think there are quite a few higher priority items. Simon Lessard wrote: Hello again Jeanne, I see... It does less than I was thinking, but I think the issue I was seeing can still happen if the renderer you want to use also uses the resourceKeyMap. Let say that menuBar has af|menuBar and af|menuBar::something classes. However, the something is actually rendered by another renderer, so I would map somethingOriginalKey to af|menuBar::something right? Let say that I want to create XYZ component and use menuBar renderer. I would have to map af|XYZ and af|XYZ::something with the equivalent menuBar classes right? However, with the current pattern would it not end with: af|XYZ and af|menuBar::something being used while af|XYZ and af|XYZ::something should be what we wanted? Thanks for the nice explanation, it cleared some gray zones, ~ Simon On 8/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi Simon, This pattern was introduced to handle the case where we are using the same renderer to render different components, but we want to make sure the style classes that get rendered are for the correct component. If I'm writing a renderer for the XYZ component, and I want to use the menuBar renderer code, then I would map the menuBar style classes to XYZ style classes. That way I'll get XYZ style classes for my XYZ component. If a renderer doesn't share rendering code, then they don't need to do this. Another thing the renderer could do is to use renderer delegation. Then, the renderer could have a inner class that overrides the MenuBar renderer, for example, and overrides the methods which return style classes (this assumes there are appropriate hooks for this in the renderer you are overriding, which probably isn't the case) I don't understand your grandparent example well enough to comment on it. First I wanted to be sure you understand what the purpose of this map is. - Jeanne Simon Lessard wrote: Hello all, It seems that most renderers use RenderingContext.setSkinResourceKeyMap to temporarily alter the skin selectors used by their children. The use case is almost always : Map original = RenderingContext.getSkinResourceKeyMap(); RenderingContext.setSkinResourceKeyMap(newMap); // do some work RenderingContext.setSkinResourceKeyMap(original); I see three problems with that pattern. First, there's no way to enforce it. Secondly, it can lead to some unworking case. Imagine we have something like: grand-parent parent child/ /parent /grand-parent Now let say child uses af|component, af|component::part and af|component::part:state selectors. Let assume that grand-parent redirects af|component to GrandParentReplacement and parent redirects af|component::part to ParentReplacement and af|component::part:state to af|component. The above pattern will result in the following redirections: - af|component -- not redirected - af|component::part -- ParentReplacement - af|component::part:state -- af|component However, the above result is most likely not what was wanted. I believe it should be more like: - af|component -- GrandParentReplacement - af|component::part -- ParentReplacement - af|component::part:state -- GrandParentReplacement So I would suggest to change setSkinResourceKeyMap to pushSkinResourceKeyMap and add a popSkinResourceKeyMap as well as a peekSkinResourceKeyMap. The selector resolution could then move through the whole redirection chain as well as simplify the code required inside renderer. The above code would become: RenderingContext.pushSkinResourceKeyMap(newMap); // do some work RenderingContext.popSkinResourceKeyMap(); The third problem I see with this pattern is that parents has to know what kind of children they will contain, which is really bad for the component developers working outside Trinidad project but wanting to use its internal feature (yes I know, that API is not currently public). I don't see any solution to this problem yet, but I believe we should find a standardized way to handle children selector redirection because some Trinidad components seem a bit too strongly coupled together imho. Regards, ~ Simon
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver and onPress)
Well, right now they can't get gradients AND rounded borders. I seem to
remember there is no way currently, although it probably could be added,
to put gradient backgrounds on our generated images.
If they have to give us button-bits anyway, could we use html tables or
something to piece them together so they could get rounded corners and
gradient backgrounds?
- Jeanne
[EMAIL PROTECTED] wrote:
Note to self: Test with latest build before saying anything...
Tabs no longer use image package. However, while thinking about it last
night, I'm not sure that desuporting generated image buttons is a so nice
idea. I would rather like to see a new component like
tr:composedImageButton or something like that working exactly like the
current tr:commandButton and remove image generation from
tr:commandButton. This way users would have all possibilities: create
buttons with gradients and create buttons with round borders.
¬ Simon
I just tested those style classes, they're prety nice.However, I think
the results are better with simply the following
.ButtonCellIE
{
margin: 0px;
padding: 0px;
background-image: url(background.jpg);
}
.ButtonStyleIE
{
background-color: transparent;
}
.ButtonCellFirefox
{
margin: 0px;
padding: 0px;
}
.ButtonStyleFirefox
{
background-image: url(background.jpg);
}
It seems that Firefox supports button background-images natively, it
works even without the cell and the result is better oveall. Sadly div
does not work well.
This solution also has its drawback since you cannot use round borders.
For buttons it might not be a huge issue, but navigationPane might hurt,
especially for tabs. So until we can provide users with an equal
flexibility system for tabs I will be
-1 on removing image package
+1 on removing button dependancy toward image package.
¬ Simon
Jeanne Waldman [EMAIL PROTECTED]
2006-08-17 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a
styleClass on both.
The problem was that he couldn't style buttons that were rendered as a
part
of another component, so some of his buttons had a gradient background and
some didn't.
I recommend that we wrap our button html tag with
a div or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #66; border-right: 1px solid #66;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
afh:cellFormat styleClass=ButtonCell
af:commandButton text=#{webStrings.OK}
action=#{actions.createFolder}
styleClass=ButtonStyle/
/afh:cellFormat
Adam Winer wrote:
Oh, that...
That opens up a new topic: what the heck should we do about
Trinidad button skinning?
As a little background: ADF Faces had a large image-generation
subsystem code-named Tecate that took text, metadata, and
other images, and composited them into single images. This
let us have fancy-looking buttons containing, for example,
translatable text. Instead of trying to get thousands of button
images translated (which would have been a nightmare), developers
just got text translated as normal and Tecate did the heavy lifting
at runtime.
It was used for more than buttons - tabs and global buttons (now
hint=buttons on navigationPane) also went through this system.
At a certain point, we decided this was just a bad idea, and that a
better approach was a straightforward HTML and CSS skinning
approach. So, most of the code moved away from Tecate.
As of Trinidad, though, buttons were still left on it. And, as a
result,
we have the large org.apache.myfaces.trinidadinternal.image package -
and all of the code in there - just for one simple feature.
I'd really like to come up with a simpler button skinning strategy,
and kill the image package altogether. The simplest possible
strategy is just HTML along the lines of:
button class=af_commandButton.../button
-- Adam
Re: Button skinning (was Re: [Proposal] Skin hooks for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a styleClass on
both.
The problem was that he couldn't style buttons that were rendered as a part
of another component, so some of his buttons had a gradient background and some didn't.
I recommend that we wrap our button html tag with
a div or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #66; border-right: 1px solid #66;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
afh:cellFormat styleClass=ButtonCell
af:commandButton text=#{webStrings.OK}
action=#{actions.createFolder}
styleClass=ButtonStyle/
/afh:cellFormat
Adam Winer wrote:
Oh, that...
That opens up a new topic: what the heck should we do about
Trinidad button skinning?
As a little background: ADF Faces had a large image-generation
subsystem code-named Tecate that took text, metadata, and
other images, and composited them into single images. This
let us have fancy-looking buttons containing, for example,
translatable text. Instead of trying to get thousands of button
images translated (which would have been a nightmare), developers
just got text translated as normal and Tecate did the heavy lifting
at runtime.
It was used for more than buttons - tabs and global buttons (now
hint=buttons on navigationPane) also went through this system.
At a certain point, we decided this was just a bad idea, and that a
better approach was a straightforward HTML and CSS skinning
approach. So, most of the code moved away from Tecate.
As of Trinidad, though, buttons were still left on it. And, as a result,
we have the large org.apache.myfaces.trinidadinternal.image package -
and all of the code in there - just for one simple feature.
I'd really like to come up with a simpler button skinning strategy,
and kill the image package altogether. The simplest possible
strategy is just HTML along the lines of:
button class=af_commandButton.../button
-- Adam
On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unless those exist and are not documented it would not work because the
button image is composed of 8 part, one background and one text all
merged
together in a single image. So using CSS :hover and :active on the 9
selectors would not work. Furthermore if I remember well :hover and
:active works only for links under IE.
Maybe those are managed by the skin already but I never figured it out
though. Jeanne, can you confirm please?
¬Simon
Adam Winer [EMAIL PROTECTED]
2006-08-16 16:47
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: [Proposal] Skin hooks for mouseOver and
onPress
Isn't this just :hover and :active?
-- Adam
On 8/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello all,
I just had a flashback from my ADF Faces project. In that project we
wanted to use a different image on mouse over event. In the end we had
to
use commandLink with an image and some JavaScript events instead.
So my
suggestion about button would be to add skin state hooks for mouseOver
and
mouseDown occuring on buttons to improve their LF and thus user
experience.
¬Simon
Re: Tr : Skin selector XML, where?
skin-selectors.xml in trinidad/src/site/xdoc [EMAIL PROTECTED] wrote: Oh dang... I sent it on the wrong list at first... ¬ Simon - Forwarded by Simon Lessard/NOTES on 2006-08-17 10:18 - [EMAIL PROTECTED] 2006-08-17 09:37 Please respond to adffaces-user To: adffaces-user@incubator.apache.org cc: Subject:Skin selector XML, where? Hello Jeanne, Can you tell me where the XML file used to store skin selector information was added when you have time please? Thanks, ¬ Simon
Re: Little usability issue with inputNumberSpinbox component
I'll look into moving that up.
Thanks,
Jeanne
[EMAIL PROTECTED] wrote:
I'm not sure if it will be generalized, but I think the increment arrow is
a bit hard to hit on the new inputSpinbox component. I believe it would be
better to place the onmousedown event on the td rather than the anchor
element.
Do you think it would be ok or do you see another potential issue ?
¬ Simon
Jeanne Waldman [EMAIL PROTECTED]
2006-08-17 12:55
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: Button skinning (was Re: [Proposal] Skin hooks
for mouseOver and onPress)
We had a customer that wanted to put background images on our buttons.
He couldn't do this with our buttons unless they had a container
(I haven't tested this in ages, but I remember that he was right), so what
he did was wrap our command button in a afh:cellFormat and put a
styleClass on both.
The problem was that he couldn't style buttons that were rendered as a
part
of another component, so some of his buttons had a gradient background and
some didn't.
I recommend that we wrap our button html tag with
a div or something so that the skinner can put background images on the
buttons.
The following is how he skinned the commandButton:
.ButtonCell
{
margin: 0px; padding: 0px;
border-top: 1px solid #afc6d7; border-left: 1px solid #afc6d7;
border-bottom: 1px solid #66; border-right: 1px solid #66;
background-repeat: repeat-x; background-position: bottom left;
background-color: #ff;
text-align: center;
vertical-align: middle;
background-image:url(/content/static/icons/buttonbg.gif)
}
.ButtonStyle
{
margin: 0px; padding: 2px 4px 2px 4px;
border: 0px;
background-color: transparent;
font: 12px Tahoma, Helvetica, sans-serif;
text-align: center;
vertical-align: middle;
cursor:pointer;
}
afh:cellFormat styleClass=ButtonCell
af:commandButton text=#{webStrings.OK}
action=#{actions.createFolder}
styleClass=ButtonStyle/
/afh:cellFormat
Adam Winer wrote:
Oh, that...
That opens up a new topic: what the heck should we do about
Trinidad button skinning?
As a little background: ADF Faces had a large image-generation
subsystem code-named Tecate that took text, metadata, and
other images, and composited them into single images. This
let us have fancy-looking buttons containing, for example,
translatable text. Instead of trying to get thousands of button
images translated (which would have been a nightmare), developers
just got text translated as normal and Tecate did the heavy lifting
at runtime.
It was used for more than buttons - tabs and global buttons (now
hint=buttons on navigationPane) also went through this system.
At a certain point, we decided this was just a bad idea, and that a
better approach was a straightforward HTML and CSS skinning
approach. So, most of the code moved away from Tecate.
As of Trinidad, though, buttons were still left on it. And, as a
result,
we have the large org.apache.myfaces.trinidadinternal.image package -
and all of the code in there - just for one simple feature.
I'd really like to come up with a simpler button skinning strategy,
and kill the image package altogether. The simplest possible
strategy is just HTML along the lines of:
button class=af_commandButton.../button
-- Adam
On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Unless those exist and are not documented it would not work because the
button image is composed of 8 part, one background and one text all
merged
together in a single image. So using CSS :hover and :active on the 9
selectors would not work. Furthermore if I remember well :hover and
:active works only for links under IE.
Maybe those are managed by the skin already but I never figured it out
though. Jeanne, can you confirm please?
¬Simon
Adam Winer [EMAIL PROTECTED]
2006-08-16 16:47
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: [Proposal] Skin hooks for mouseOver and
onPress
Isn't this just :hover and :active?
-- Adam
On 8/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello all,
I just had a flashback from my ADF Faces project. In that project we
wanted to use a different image on mouse over event. In the end we
had
to
use commandLink with an image and some JavaScript events instead.
So my
suggestion about button would be to add skin state hooks for
mouseOver
and
mouseDown occuring on buttons to improve their LF and thus user
experience.
¬Simon
[Proposal] new prefix-name for custom skin properties
I submitted an issue about this.
I wanted to make sure we have consensus on -oam- instead of -ora- before
I implement this.
Key: ADFFACES-56
URL: http://issues.apache.org/jira/browse/ADFFACES-56
Project: MyFaces ADF-Faces
Type: Improvement
Thanks,
Jeanne
John Fallows wrote:
On 6/25/06, Martin Marinschek [EMAIL PROTECTED] wrote:
+1 for the proposal in a whole
+1 for using inhibit - I like it more than reset or null
Agreed. +1 proposal, +1 inhibit.
suggestion for ca new prefix-name: changing ora to oam (org apache
myfaces)
Yes, this is another part of the repackaging effort. Are we limited to 3
chars here?
tc,
-john.
regards,
Martin
On 6/24/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I have another skinning proposal. This is a useful feature that is in
xss that I think we should port to skinning css. It is the css
property
resetting feature.
A bit of background first. Trinidad defines a base skin. We call this
skin 'simple'. It defines basic, simple css properties for the
Trinidad
components. An application developer can create a skin, and this
automatically extends the simple skin. Think of the simple skin as a
base class in Java. You can extend one skin from another, but they are
all derived from the base skin.
When a skin extends the base skin, it is ADDING style properties to
the
base skin's style properties.
Let's say the base skin defines the font-size for the
af|inputText::label selector. This means that your skin will inherit
this font. Your skin can redefine font-size, and put a new font-size
instead. But currently, you can't say, I don't want any font-size
specified on af|inputText::label.
I'm proposing that we come up with a skinning syntax that allows the
person writing a skin to do this.
We have this feature in the .xss syntax. In .xss, you'd do this:
style name=foo resetProperties=true/
or to reset one property, you'd do this:
style name=foo
property name=font-size/
/style
How could we do this in css-syntax?
One proposal is to add a special property like our '-ora-rule-ref'
property. (by the way, we'll need another discussion on whether to
change the -ora- prefix, and what to change it to).
Here is a proposal:
.foo {-ora-inhibit: all}
.bar {-ora-inhibit: text-align font-size color} // inhibit/reset/null
out these specific properties
Let me know what you think.
Thanks,
Jeanne
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Follow-up on skin issues
[EMAIL PROTECTED] wrote:
Hello,
I redid the test with the menuList, you were right about the
menuList::selected, it's just ignored completely. The bold weight I was
seeing on the selected field was coming from .AFDefaultBoldFont:alias,
sorry about that.
However, I had other comments about the skin from users. Another example
of badly answering skin is with the messages component. If the user
specifies the following selectors, he'll assume that he'll get a message
zone using a green background:
af|messages
{
background-color: green;
}
af|messages::header
{
padding-left: 20px;
}
af|messages::body
{
border-top-style: solid;
border-top-color: #ff;
border-top-width: 3px;
width: 100%;
}
Sadly, the resulting background will be gray because
.AFLightAccentBackground:alias will be used because simple skin import it
on ::body selector. Of course, one could inhibit ; background-color on
body, but again the user will have to execute the page first to figure it
out.
Also, I would like to open a discussion on the pertinence of applying
.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
the page. I think those two alone cause the most troubles for the end
user. I think we could coerce those in some predefined selectors in the
final CSS:
I think that these aliases are really nice to have because it is a quick
hook for a person to change the colors of the entire application.
If the skinner doesn't like this hook, then he can use the inhibit
feature to inhibit these properties.
AFDefaultFont:alias -- *
AFDefaultFont:alias -- h1 *
AFDefaultFont:alias -- h2 *
AFDefaultFont:alias -- h3 *
AFDefaultFont:alias -- h4 *
or
AFDefaultFont:alias -- .panelHeaderClass *
and
AFLinkForeground:alias -- a:link
or
AFLinkForeground:alias -- *:link
That way they would be applied to everything, but at a lower priority
inside the cascading style chain, thus making easier to override the style
on child elements using the skin rather than sometimes being forced to use
inlineStyle.
The skinner could add style definitions like this:
* {font-family: Ariel}
h1 * {font-family:Ariel}
then he could inhibit the AFDefaultFont:alias's properties to get this
effect.
We don't map our alias style definitions to html constructs like you are
suggesting. They are simply
mechanisms to include in other styles to make it quicker to make changes
to multiple components.
I think documenting what skin style keys include would be useful to a
skinner.
That sounds acceptale?
We could document how the skinner can inhibit these global selectors,
once we add the inhibit feature.
Regards,
Simon Lessard
Fujitsu Consulting
Re: Follow-up on skin issues
Hi Simon,
Thanks again for your feedback. It would be awesome if we could get more
feedback from users of the skinning feature.
I could see a configuration setting where you can say you want your skin
to inherit from simple or to inherit from nothing at all.
But I really think this will cause way more problems than it solves.
I think the inhibit feature would have helped so much that you wouldn't
have wanted or needed to inhibit everything. :)
And of course, we definitely need better documentation.
Ideally, we should have one source of truth -- the .xss files and base
.css files if any, and it would be awesome to be able to generate
documentation off of that that shows each skin selector and what it
includes... this would be before the step that resolves the included styles.
- Jeanne
[EMAIL PROTECTED] wrote:
Sun Certified Programmer for Java 2 Platform 1.4
Jeanne Waldman [EMAIL PROTECTED]
2006-07-10 15:47
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: Follow-up on skin issues
[EMAIL PROTECTED] wrote:
Hello,
I redid the test with the menuList, you were right about the
menuList::selected, it's just ignored completely. The bold weight I was
seeing on the selected field was coming from .AFDefaultBoldFont:alias,
sorry about that.
However, I had other comments about the skin from users. Another example
of badly answering skin is with the messages component. If the user
specifies the following selectors, he'll assume that he'll get a message
zone using a green background:
af|messages
{
background-color: green;
}
af|messages::header
{
padding-left: 20px;
}
af|messages::body
{
border-top-style: solid;
border-top-color: #ff;
border-top-width: 3px;
width: 100%;
}
Sadly, the resulting background will be gray because
.AFLightAccentBackground:alias will be used because simple skin import it
on ::body selector. Of course, one could inhibit ; background-color on
body, but again the user will have to execute the page first to figure it
out.
Also, I would like to open a discussion on the pertinence of applying
.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
the page. I think those two alone cause the most troubles for the end
user. I think we could coerce those in some predefined selectors in the
final CSS:
I think that these aliases are really nice to have because it is a quick
hook for a person to change the colors of the entire application.
If the skinner doesn't like this hook, then he can use the inhibit
feature to inhibit these properties.
The question then is how often will the skinners inhibit everything. If
inhibit is used for more than 50% of the selectors, it makes automatic
inheritance quite obsolete.
Another compromise I see would be to make it so that simple skin does not
include aliases in any pseudo-element selector, or don't use aliases at
all, that is :
af|messages {
// rule ref allowed in simple skin
}
af|messages:body {
// rule ref not allowed in simple skin
}
This would ensure that most components get easily skinned without having
to inhibit prety much everything since you often want to change the look
of the whole component. Also, if simple skin don't use any alias, it will
really be simple, once inheriting from a different skin than simple is
implemented, nothing would prevent Trinidad to have more than one base
skin: simple skin not using any rule ref and maybe minimal using what
simple skin currently uses. By the way, maybe those names should be
changed, I don't know if it's only in French, but here minimal often means
less than simple, not the other way around. Of course, it's only a
semantic debate here.
As a metric, we planned 10 days for the skin on our ADF Faces project. The
result was a 775 lines (including comments and blank lines) file that took
25 days to create. Comparatively, all other tasks were finished about 10%
faster than planned. Of course, that's only one project and one cannot
generalize from it. Furthermore, inbithit was not supported at this time
either. That being said, I believe there's still some teachings to get out
of it.
AFDefaultFont:alias -- *
AFDefaultFont:alias -- h1 *
AFDefaultFont:alias -- h2 *
AFDefaultFont:alias -- h3 *
AFDefaultFont:alias -- h4 *
or
AFDefaultFont:alias -- .panelHeaderClass *
and
AFLinkForeground:alias -- a:link
or
AFLinkForeground:alias -- *:link
That way they would be applied to everything, but at a lower priority
inside the cascading style chain, thus making easier to override the
style
on child elements using the skin rather than sometimes being forced to
use
inlineStyle.
The skinner could add style definitions like this:
* {font-family: Ariel}
h1 * {font-family:Ariel}
then he could inhibit the AFDefaultFont:alias's properties to get
Re: Tr :Re: [Proposal] inhibiting css properties in skin definition file
I'll give this a try when I get a chance. Thanks.
- Jeanne
[EMAIL PROTECTED] wrote:
Hello,
Maybe I didn't copy the example properly. Here's a working (unworking)
example I just tested:
af|menuList::selected
{
background-color: blue;
}
This won't show any change in the page as .AFLightBackground:alias will
define the used background-color.
Simon Lessard
DMR Conseil Inc. (http://www.dmrconseil.ca)
Téléphone : (418) 653-6881
Sun Certified Programmer for Java 2 Platform 1.4
Jeanne Waldman [EMAIL PROTECTED]
2006-07-05 18:52
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject:Re: Tr :Re: [Proposal] inhibiting css properties
in skin definition file
Hello again,
I just ran your example of
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
by putting this in the purple skin (purpleSkin.css file)
And I created a new skin called purpleExtension. In
purpleExtensionSkin.css, I add this:
.someSelector
{
color: yellow;
}
Then I created a purpleExtension skin that extends the purple skin by
adding this in the adf-faces-skins.xml file:
skin
id
purpleExtension.desktop
/id
family
purpleExtension
/family
extendspurple.desktop/extends
render-kit-id
org.apache.myfaces.adf.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleExtensionSkin.css
/style-sheet-name
/skin
And I added this to a .jspx demo:
af:outputText value=HELLO THERE!
styleClass=someSelector/
And when the skin was purpleExtension it was blue background, yellow
color.
And when the skin was purple it was blue background, red color.
So, it works for me.
- Jeanne
Jeanne Waldman wrote:
Hi there,
Yes, I have some comments (been busy).
First of all, it appears to be a bug that the skin's selector's
property does not take precedence. We should submit an issue for this.
As for the other issues:
1) Add a new keyword like -super or -inherit that would make the current
selector inherit the properties defined by its parent
-Jeanne-:
The skinning css file should work like css, in that it cascades the
styles from the parent skins. So I think the -super is implicit, and
we shouldn't have a -super keyword.
2) Add a -suppressProperty or -inhibit property to remove some items
added
by calling a -super
- Jeanne -:
This is the same as my proposal:
.bar {-ora-inhibit: text-align font-size color} //
inhibit/reset/null
3) Add also a -suppressImport or -inhibitImport that would remove an
-ora-rule-ref from the parent.
- Jeanne -:
This is similar to the -ora-inhibit: all feature. We don't
necessarily know what aliases our parent has included. It is much
easier to inhibit all, then add back what you care about.
4) Give priority to the more specific over the more general relatively
to
the imported aliases.
- Jeanne -:
I agree. I didn't think it worked this way, so it must be a bug.
I'll want to do some tests of my own.
[EMAIL PROTECTED] wrote:
Hello,
We would like to work on this improvement. Is there any comments
about our suggestion ? If no, then we will proceed as indicated
below. Otherwise, please let us know.
___
Eric Marcoux...
Fujitsu Consulting
(http://www.fujitsu.com/ca/en/services/consulting/)
https://secure.dmr.com/go/www.dmrconseil.ca%29
Member of the quebec JUG (http://www.javaquebec.org)
https://secure.dmr.com/go/www.javaquebec.org%29
Sun Certified Programmer for Java 2 Platform 1.4
Sun Certified Web Component Developer for J2EE
Sun Certified Business Component Developer for J2EE
-Réacheminé par Eric Marcoux-QC/DMR/CA le 05/07/2006 03:21PM -
Pour : adffaces-dev@incubator.apache.org
De : [EMAIL PROTECTED]
Date : 03/07/2006 08:33AM
cc: adffaces-dev@incubator.apache.org, [EMAIL PROTECTED]
Objet : Re: [Proposal] inhibiting css properties in skin
definition file
Hello,
I just finished a project using ADF Faces and I have some insight
to share
about the problems we had with the skin.
I like the inhitbit idea. However, I think the semantic of
overriding a
selector should be modified. More specifically, let examine the
current
ADF Faces behavior.
In Base skin definition let say we have
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
In customSkin.css we got
.someSelector
{
color: yellow;
}
Then, the resulting CSS will use
.someSelector
{
color: red;
background-color: blue;
}
Which is a very odd behavior for two reason:
It seems that the -ora-rule-ref get resolved after everything
else, thus
overwriting style placed in the overriden
Re: Tr :Re: [Proposal] inhibiting css properties in skin definition file
Can you give me another example?
It appears that the Trinidad code no longer has this skinning key (this
is a bug).
Also, are you using the Trinidad code in your tests?
- Jeanne
Jeanne Waldman wrote:
I'll give this a try when I get a chance. Thanks.
- Jeanne
[EMAIL PROTECTED] wrote:
Hello,
Maybe I didn't copy the example properly. Here's a working
(unworking) example I just tested:
af|menuList::selected
{
background-color: blue;
}
This won't show any change in the page as .AFLightBackground:alias
will define the used background-color.
Simon Lessard
DMR Conseil Inc. (http://www.dmrconseil.ca)
Téléphone : (418) 653-6881
Sun Certified Programmer for Java 2 Platform 1.4
Jeanne Waldman [EMAIL PROTECTED]
2006-07-05 18:52
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:Subject:Re: Tr :Re: [Proposal] inhibiting
css properties in skin definition file
Hello again,
I just ran your example of
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
by putting this in the purple skin (purpleSkin.css file)
And I created a new skin called purpleExtension. In
purpleExtensionSkin.css, I add this:
.someSelector
{
color: yellow;
}
Then I created a purpleExtension skin that extends the purple skin by
adding this in the adf-faces-skins.xml file:
skin
id
purpleExtension.desktop
/id
family
purpleExtension
/family
extendspurple.desktop/extends
render-kit-id
org.apache.myfaces.adf.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleExtensionSkin.css
/style-sheet-name
/skin
And I added this to a .jspx demo:
af:outputText value=HELLO THERE!
styleClass=someSelector/
And when the skin was purpleExtension it was blue background, yellow
color.
And when the skin was purple it was blue background, red color.
So, it works for me.
- Jeanne
Jeanne Waldman wrote:
Hi there,
Yes, I have some comments (been busy).
First of all, it appears to be a bug that the skin's selector's
property does not take precedence. We should submit an issue for this.
As for the other issues:
1) Add a new keyword like -super or -inherit that would make the
current
selector inherit the properties defined by its parent
-Jeanne-:
The skinning css file should work like css, in that it cascades
the styles from the parent skins. So I think the -super is implicit,
and we shouldn't have a -super keyword.
2) Add a -suppressProperty or -inhibit property to remove some items
added
by calling a -super
- Jeanne -:
This is the same as my proposal:
.bar {-ora-inhibit: text-align font-size color} //
inhibit/reset/null
3) Add also a -suppressImport or -inhibitImport that would remove an
-ora-rule-ref from the parent.
- Jeanne -:
This is similar to the -ora-inhibit: all feature. We don't
necessarily know what aliases our parent has included. It is much
easier to inhibit all, then add back what you care about.
4) Give priority to the more specific over the more general
relatively
to
the imported aliases.
- Jeanne -:
I agree. I didn't think it worked this way, so it must be a bug.
I'll want to do some tests of my own.
[EMAIL PROTECTED] wrote:
Hello,
We would like to work on this improvement. Is there any comments
about our suggestion ? If no, then we will proceed as indicated
below. Otherwise, please let us know.
___
Eric Marcoux...
Fujitsu Consulting
(http://www.fujitsu.com/ca/en/services/consulting/)
https://secure.dmr.com/go/www.dmrconseil.ca%29
Member of the quebec JUG (http://www.javaquebec.org)
https://secure.dmr.com/go/www.javaquebec.org%29
Sun Certified Programmer for Java 2 Platform 1.4
Sun Certified Web Component Developer for J2EE
Sun Certified Business Component Developer for J2EE
-Réacheminé par Eric Marcoux-QC/DMR/CA le 05/07/2006 03:21PM -
Pour : adffaces-dev@incubator.apache.org
De : [EMAIL PROTECTED]
Date : 03/07/2006 08:33AM
cc: adffaces-dev@incubator.apache.org, [EMAIL PROTECTED]
Objet : Re: [Proposal] inhibiting css properties in skin
definition file
Hello,
I just finished a project using ADF Faces and I have some insight
to share
about the problems we had with the skin.
I like the inhitbit idea. However, I think the semantic of
overriding a
selector should be modified. More specifically, let examine the
current
ADF Faces behavior.
In Base skin definition let say we have
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
In customSkin.css we got
.someSelector
{
color: yellow;
}
Then, the resulting CSS will use
.someSelector
{
color: red
Re: Tr : Re: ProcessTrain Number of Stops before segmenting configurable?
That's a good analysis, and what we usually go through when we decide on
an attribute or a skin property.
I personally don't think we'd need it at the specific level, which I've
been calling 'per instance'. I think global to the processTrain within
an application/skin is good enough.
- Jeanne
[EMAIL PROTECTED] wrote:
Hello,
I could do that as well since it would indeed be a nice enhancement,
However, I don't know what would be best between a skin property and a tag
attribute. Pro of skin property is that since the skin knows what kind of
images it use, it would be the best placed to know how many station can be
safely rendered. However, skin property is global and will prevent any
overload at specific level. Maybe we could have both, a
-default-visible-number-stations and a tag atttribute, the tag attribute,
if present would be the one used?
Regards,
Simon Lessard
Fujitsu Consulting
- Forwarded by Simon Lessard/NOTES on 2006-07-06 16:26 -
Jeanne Waldman [EMAIL PROTECTED]
2006-07-06 16:20
Please respond to adffaces-user
To: adffaces-user@incubator.apache.org
cc:
Subject:Re: ProcessTrain Number of Stops before
segmenting configurable?
This could be an enhancement. It would be a good example of using a
skinning property.
You could add a skin property, like -ora-number-visible-stations (note,
I'll have to follow through on the thread regarding changing the -ora-
to something else).
So in the skin file you'd do this:
af|processTrain {-ora-number-visible-stations: 10 }
(The default would be 6)
Then we'd need to change the train renderer to honor this number instead
of hard-coding it to 6. Then ALL processTrain components that are
defined in the application will use this property value defined in the
skin.
- Jeanne
[EMAIL PROTECTED] wrote:
Hello,
Threshold is currently fixed to 6 visible stations and add a 7th that is
the arrow pointing to the next set of steps. This parameter is not
configurable at this time.
Sorry,
Simon Lessard
Fujitsu Consulting
Re: inhibiting css properties in skin definition file
Before I can comment on your examples, I'd like to be able run them. :)
When I run the menuList demo, my html is
lispan class=OraNav3
a onclick=submitForm('_idJsp3',1,{source:'_idJsp11:_idJsp12'});return false;
href=# class=OraLinkPage 1/a/span/li
lispan class=OraNav3Selected
a onclick=submitForm('_idJsp3',1,{source:'_idJsp11:_idJsp13'});return false;
href=# class=OraLinkPage 2/a/span/li
lispan class=OraNav3
a onclick=submitForm('_idJsp3',1,{source:'_idJsp11:_idJsp14'});return false;
href=# class=OraLinkPage 3/a/span/li
... you'll see there is no af_menuList_selected, etc. Do you see something
different?
Which demo are you running?
[EMAIL PROTECTED] wrote:
Hmmm... strange... I just reproduced it using the current snapshot
release on Trinidad site and the selector works fine. Here's my skin.
.AFDefaultFont:alias {
color: inherit;
font-size: 10pt;
font-weight: inherit;
}
.AFLightBackground:alias {
background-color : red;
}
af|menuList { }
af|menuList::selected {
font-weight: bold;
background-color: blue;
}
and the page:
af:menuList listStyle=none
af:commandNavigationItem text=Selected selected=true/
af:commandNavigationItem text=Unselected/
/af:menuList
You'll see that the ::selected works because of the bold font weight that
will be given to the selected item.
Note that if you remove the inherit from AFDefaultFont:alias, the font
will no longer be bold, which is another skin/rendering bug as the
af|menuList:selected class is applied on the td element while the
default font is applied directly on the a and if you don't specify any
weight in that font alias, you'll inherit the font-weight: normal from
base skin. That very strange behavior almost drove crazy the one in charge
of the skin on the project we finished 1 week ago.
With inhibit, you would have to override DefaultFont to inhibit
font-weight This is much better than without the option, but I believe it
will still be annoying for the end user, hence why I proposed to not
inherit from parent by default. Without inherit by default, the selector
would still have to be overridden, ut the user would not have to inhibit
anything.
The above example is, I believe, a good example why automatically
inheriting the parent's properties is not really respecting the cascading
style rule. An user creating the following skin would expect to see a
menuList with both items using a font-size of 10pt with the selected item
being in bold with a blue background:
.AFDefaultFont:alias {
font-size: 10pt;
}
af|menuList::selected {
font-weight: bold;
background-color: blue;
}
I'll try to post more irritating example we found out while creating our
skin.
Simon Lessard
Fujitsu Consulting
Re: Tr :Re: [Proposal] inhibiting css properties in skin definition file
{
-super;
-ora-rule-ref(selector: aliasChild:alias);
someProperty3 : someValue6;
}
Then the resulting CSS for the parent skin would use for selector
aSelector:
someProperty1 : someValue4;
someProperty2 : someValue2;
someProperty3 : someValue3;
and the resulting CSS for child skin would use:
someProperty1 : someValue4;
someProperty2 : someValue5;
someProperty3 : someValue6;
Sounds good?
Simon Lessard
DMR Conseil Inc. (http://www.dmrconseil.ca
http://www.dmrconseil.ca/)
Téléphone : (418) 653-6881
Sun Certified Programmer for Java 2 Platform 1.4
John Fallows [EMAIL PROTECTED]
2006-06-29 20:17
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org,
[EMAIL PROTECTED]
cc:
Subject:Re: [Proposal] inhibiting css properties in
skin
definition file
On 6/25/06, Martin Marinschek [EMAIL PROTECTED] wrote:
+1 for the proposal in a whole
+1 for using inhibit - I like it more than reset or null
Agreed. +1 proposal, +1 inhibit.
suggestion for ca new prefix-name: changing ora to oam (org apache
myfaces)
Yes, this is another part of the repackaging effort. Are we
limited to 3
chars here?
tc,
-john.
regards,
Martin
On 6/24/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I have another skinning proposal. This is a useful feature
that is in
xss that I think we should port to skinning css. It is the css
property
resetting feature.
A bit of background first. Trinidad defines a base skin. We
call this
skin 'simple'. It defines basic, simple css properties for the
Trinidad
components. An application developer can create a skin, and this
automatically extends the simple skin. Think of the simple
skin as a
base class in Java. You can extend one skin from another, but
they are
all derived from the base skin.
When a skin extends the base skin, it is ADDING style
properties to
the
base skin's style properties.
Let's say the base skin defines the font-size for the
af|inputText::label selector. This means that your skin will
inherit
this font. Your skin can redefine font-size, and put a new
font-size
instead. But currently, you can't say, I don't want any font-size
specified on af|inputText::label.
I'm proposing that we come up with a skinning syntax that
allows the
person writing a skin to do this.
We have this feature in the .xss syntax. In .xss, you'd do this:
style name=foo resetProperties=true/
or to reset one property, you'd do this:
style name=foo
property name=font-size/
/style
How could we do this in css-syntax?
One proposal is to add a special property like our '-ora-rule-ref'
property. (by the way, we'll need another discussion on whether to
change the -ora- prefix, and what to change it to).
Here is a proposal:
.foo {-ora-inhibit: all}
.bar {-ora-inhibit: text-align font-size color} //
inhibit/reset/null
out these specific properties
Let me know what you think.
Thanks,
Jeanne
--
http://www.irian.at http://www.irian.at/
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: Tr :Re: [Proposal] inhibiting css properties in skin definition file
Hello again,
I just ran your example of
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
by putting this in the purple skin (purpleSkin.css file)
And I created a new skin called purpleExtension. In
purpleExtensionSkin.css, I add this:
.someSelector
{
color: yellow;
}
Then I created a purpleExtension skin that extends the purple skin by
adding this in the adf-faces-skins.xml file:
skin
id
purpleExtension.desktop
/id
family
purpleExtension
/family
extendspurple.desktop/extends
render-kit-id
org.apache.myfaces.adf.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleExtensionSkin.css
/style-sheet-name
/skin
And I added this to a .jspx demo:
af:outputText value=HELLO THERE! styleClass=someSelector/
And when the skin was purpleExtension it was blue background, yellow color.
And when the skin was purple it was blue background, red color.
So, it works for me.
- Jeanne
Jeanne Waldman wrote:
Hi there,
Yes, I have some comments (been busy).
First of all, it appears to be a bug that the skin's selector's
property does not take precedence. We should submit an issue for this.
As for the other issues:
1) Add a new keyword like -super or -inherit that would make the current
selector inherit the properties defined by its parent
-Jeanne-:
The skinning css file should work like css, in that it cascades the
styles from the parent skins. So I think the -super is implicit, and
we shouldn't have a -super keyword.
2) Add a -suppressProperty or -inhibit property to remove some items
added
by calling a -super
- Jeanne -:
This is the same as my proposal:
.bar {-ora-inhibit: text-align font-size color} //
inhibit/reset/null
3) Add also a -suppressImport or -inhibitImport that would remove an
-ora-rule-ref from the parent.
- Jeanne -:
This is similar to the -ora-inhibit: all feature. We don't
necessarily know what aliases our parent has included. It is much
easier to inhibit all, then add back what you care about.
4) Give priority to the more specific over the more general relatively to
the imported aliases.
- Jeanne -:
I agree. I didn't think it worked this way, so it must be a bug.
I'll want to do some tests of my own.
[EMAIL PROTECTED] wrote:
Hello,
We would like to work on this improvement. Is there any comments
about our suggestion ? If no, then we will proceed as indicated
below. Otherwise, please let us know.
___
Eric Marcoux...
Fujitsu Consulting
(http://www.fujitsu.com/ca/en/services/consulting/)
https://secure.dmr.com/go/www.dmrconseil.ca%29
Member of the quebec JUG (http://www.javaquebec.org)
https://secure.dmr.com/go/www.javaquebec.org%29
Sun Certified Programmer for Java 2 Platform 1.4
Sun Certified Web Component Developer for J2EE
Sun Certified Business Component Developer for J2EE
-Réacheminé par Eric Marcoux-QC/DMR/CA le 05/07/2006 03:21PM -
Pour : adffaces-dev@incubator.apache.org
De : [EMAIL PROTECTED]
Date : 03/07/2006 08:33AM
cc: adffaces-dev@incubator.apache.org, [EMAIL PROTECTED]
Objet : Re: [Proposal] inhibiting css properties in skin
definition file
Hello,
I just finished a project using ADF Faces and I have some insight
to share
about the problems we had with the skin.
I like the inhitbit idea. However, I think the semantic of
overriding a
selector should be modified. More specifically, let examine the
current
ADF Faces behavior.
In Base skin definition let say we have
someAlias:alias
{
color: red;
}
.someSelector
{
-ora-rule-ref(selector:someAlias:alias);
background-color: blue;
}
In customSkin.css we got
.someSelector
{
color: yellow;
}
Then, the resulting CSS will use
.someSelector
{
color: red;
background-color: blue;
}
Which is a very odd behavior for two reason:
It seems that the -ora-rule-ref get resolved after everything
else, thus
overwriting style placed in the overriden selector.
With inhibit, you could suppress the background-color. However, I
don't
know if that's the best solution. Let think in OOP:
What happen when you override a method? The parent method will
never be
called and thus, you'll never automatically inherit some
treatment, unless
you do a call to super.methodName.
This would be, I believe, the best way to work with the skin as
well since
you don't have to know what properties are set by the parent.
Considering
it's planned to be able to extends any skin in the future, I
believe it
will be hard for the framework users to know all the properties
they need
to suppress from the parent
[Proposal] inhibiting css properties in skin definition file
Hi there,
I have another skinning proposal. This is a useful feature that is in
xss that I think we should port to skinning css. It is the css property
resetting feature.
A bit of background first. Trinidad defines a base skin. We call this
skin 'simple'. It defines basic, simple css properties for the Trinidad
components. An application developer can create a skin, and this
automatically extends the simple skin. Think of the simple skin as a
base class in Java. You can extend one skin from another, but they are
all derived from the base skin.
When a skin extends the base skin, it is ADDING style properties to the
base skin's style properties.
Let's say the base skin defines the font-size for the
af|inputText::label selector. This means that your skin will inherit
this font. Your skin can redefine font-size, and put a new font-size
instead. But currently, you can't say, I don't want any font-size
specified on af|inputText::label.
I'm proposing that we come up with a skinning syntax that allows the
person writing a skin to do this.
We have this feature in the .xss syntax. In .xss, you'd do this:
style name=foo resetProperties=true/
or to reset one property, you'd do this:
style name=foo
property name=font-size/
/style
How could we do this in css-syntax?
One proposal is to add a special property like our '-ora-rule-ref'
property. (by the way, we'll need another discussion on whether to
change the -ora- prefix, and what to change it to).
Here is a proposal:
.foo {-ora-inhibit: all}
.bar {-ora-inhibit: text-align font-size color} // inhibit/reset/null
out these specific properties
Let me know what you think.
Thanks,
Jeanne
Re: [Proposal] skinning platform, agent, and language features
I have another comment to add to my email.
Look at the css spec definition for pseudo-elements and pseudo-classes
below:
* Pseudo-elements create abstractions about the document tree beyond
those specified by the document language. For instance, document
languages do not offer mechanisms to access the first letter or
first line of an element's content. CSS pseudo-elements allow
style sheet designers to refer to this otherwise inaccessible
information. Pseudo-elements may also provide style sheet
designers a way to assign style to content that does not exist in
the source document (e.g., the :before and :after
generate.html#before-after-content pseudo-elements give access
to generated content).
* Pseudo-classes classify elements on characteristics other than
their name, attributes or content; in principle characteristics
that cannot be deduced from the document tree. Pseudo-classes may
be dynamic, in the sense that an element may acquire or lose a
pseudo-class while a user interacts with the document. The
exception is ':first-child' #first-child, which /can/ be deduced
from the document tree
Think about the Trinidad components as html components. Just like a html
component can have pieces -- first letter, first line, a Trinidad
component can have pieces ::label, ::content.
We base the skinning keys around the concept of components and
pseudo-classes and pseudo-elements.
This works well with icons. Icons are usually a piece of a component,
like selectInputColor::launch-icon. It's not a style class.
The user is skinning a component, and we give them the pieces of the
component that they can skin via the skinning keys.
If we turn our skinning key format from the way it is in Trinidad to a
style-class-centric format, we lose the component-ness of the api.
Jeanne
Jeanne Waldman wrote:
Catalin Kormos wrote:
IMO, it's not just the 3rd party parsers use advantage, another
advantage
would be that most of the class selectors the skinner provides would
end up
as they were specified in the final CSS. After all, most components will
just define a list of class selectors that can be used to customize
their
appearence, right? or how do you see this generaly?
True.
In case of a component that can be in more than one state at one
time, that
component will still need to let the user customize each state's style
separately, as far as i can tell, and then it will renderer the
corresponding class selectors in its class attribute, right? (some
helper
class could take care of determining the right selectors).
I would simply let the user use the composite style classes, like
af_inputText.AFDisabled.AFSomeOtherState
so that we don't have to document all the possible combination of states.
Let's say there are 5 states a component can be in. That's a lot of
combinations.
About the :hover issue, if we take af:inputText disabled='true'/, with
CSS2 only, the skinner could have at his disposal a class selector
.af-inputText-disabled and in case he wants to change that style on
mouse
over, he could add the following selector
.af-inputText-disabled:hover to
the skin, and have both selectors rendered as they were specified by
him, no
transformation needed. (this works for most browsers, at least IE and
Opera
won't know about this for anything else than links, but there are
solutions
to make them work as expected for any html element). The final html code
would look like input type=text disabled='true'
class=af-inputText-disabled/
With DHTML, the user could have two class selectors, one for disabled
and
one for disabled:hover, .af-inputText-disabled and
.af-inputText-disabled-hover, and the mouse over is detected with JS
which
could interchange the selector in the class attribute.
Overall, I don't have a problem with simply documenting the style
classes that
we output, instead of putting it in a css-3 format. However, the idea
when we
came up with the css-3 format is that we don't want to document our
css style
classes, because those can change, and we don't want people to rely on
those,
and I think if we documented our css style classes, they would be more
inclined to rely on them.
Instead we document an 'api' -- the css-3 skinning keys, which is an
abstraction of the styleclasses . We can then map these
to the actual style classes if we want or the html implementation,
like, af|processTrain::step can map to .af_processTrain A{}.
Then the html implementation can change to something else, and behind
the scenes
we can change the mapping, and the user won't have to change his
skinning definitions.
Looking forward to your comments.
Regards,
Catalin
On 6/21/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
So are you saying the benefit of css2-syntax instead of css-3 syntax is
that we can use a 3rd party parser, and that is it?
The namespace is in css-3 syntax, but really that is it, right
Re: [Proposal] skinning platform, agent, and language features
I never commented on this email I just realized. See below. Catalin Kormos wrote: Hi Adam, Sorry if this was confusing, i certainly wouldn't want to write a pretty new framework for skinning, and this to be used only by Tomahawk. As Martin mentioned we did compare existing approaches besides Trinidad's, like the one from Tobago and I also took a look at Exadel Visual Component Platform's skinning. As far as i know these are all the current approaches for JSF and Trinidad's is the one choosed to be based on, all the features it offers are realy nice and there is room for more, like what Jeanne would like to implement, right? The goal is to work on making the Trinidad's skinning framework become the skinning framework for MyFaces. There are things to be changed though. Like going all the way with CSS, and not use XSS for the base skins, allow skins to extend each other and not just a base skin, and allow @import rules to be used. Our goal is to get rid of XSS for base skins as well, if possible. We first need to add all the features that are in XSS to CSS before we can do that. In Trinidad, skins can extend other skins. In JDeveloper 10.1.3, you couldn't do this, but in Trinidad, you can. You the extends element in the adf-faces-skins.xml file. Yes, I'd like @import rules to be used, too. That's something that we'd need before we get rid of XSS, since XSS allows this. It would be nice to know if we can pass through the @import into the generated css file or if it is another skinning file and we need to process it. The most important changes i was planning to do are related to parsing and merging the CSS files. Right now, Trinidad uses CSS3 syntax for component selectors, and has it's own way of parsing that syntax. What i want to do is use a standard CSS2 compliant parser (an implementation of SAC, http://www.w3.org/Style/CSS/SAC/), with minimal extensions, for example to recognize @agent rules, and have an internal model based on DOM Level 2 Style specifications ( http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/). This could determine also changing the naming of the component selectors to use CSS2 valid syntax from the beginning but would eliminate the transformation of CSS3 syntax into CSS2 syntax that currently occurs. I would certainly appreciate your feedback on these plans, and help to find to the best approach for bringing Trinidad skinning framework into the overall MyFaces world. Regards, Catalin On 6/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Adam, inspired means it will be based on the ADF Faces skinning framework. We evaluated Tobago's and Trinidad's thing, and we decided for the Trinidad way. Whatever extensions we write, will go to both Trinidad and Tomahawk (the definitive goal would be a common module we could both base upon). regards, Martin On 6/14/06, Adam Winer [EMAIL PROTECTED] wrote: Catalin, One quick comment: I don't see a reason to write a skinning framework inspired by the Trinidad skinning. Trinidad is part of MyFaces; why not work on taking the Trinidad skinning framework and bringing it into the overall MyFaces world? -- Adam On 6/14/06, Catalin Kormos [EMAIL PROTECTED] wrote: Hi there, I just want to say that it sounds to me like a very good ideea, having the same skin take care of browsers incompatibilities for example, rather than having different skins take care of that, with need of user intervention; i'm working on the future skinning framework for MyFaces (at least i hope it will become that), which is very much inspired by the current state of the ADF Faces skinning. It's going to be done during the Google's SoC program btw. Would be ok if i take some inspiration from this too? :) A concern of mine would be about the :lang pseudo selector. Maybe this one i didn't get quite right, but wouldn't this interfere with the standard usage of the :lang pseudo selector, for styling components that renderer their own different lang attribute value, maybe on the same page? this might not be the case for ADF Faces components though. Regards, Catalin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
build pom problem
Hi there, Does anyone know what's up with this error? Project ID: org.apache.myfaces.core:myfaces-api Reason: Error getting POM for 'org.apache.myfaces.core:myfaces-api' from the rep ository: Error transferring file org.apache.myfaces.core:myfaces-api:pom:1.1.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java-net (https://maven-repository.dev.java.net/nonav/repository/), central-corporate-legacy (http://bali.us.oracle.com:2020/maven), central-corporate (http://stacy27.us.oracle.com/maven2), snapshots-corporate (http://stacy27.us.oracle.com/maven2-snapshots) I'm figuring some website is down, and I need to wait? Thanks, Jeanne
Re: [Proposal] skinning platform, agent, and language features
So are you saying the benefit of css2-syntax instead of css-3 syntax is
that we can use a 3rd party parser, and that is it?
The namespace is in css-3 syntax, but really that is it, right?
As far as the 'states', it is possible for a component to be in more
than one state at a time.
Currently, we do not have a component like this, but I can see that it
is possible.
Like, how about if we add a state called hover to inputText, and the
end user wants special styling
when the inputText component is disabled and the user hovers over it. As
the component
writer, you could write code to detect when the mouse hovers over the
inputText, and you would
add a styleclass of p_AFHover, so the html would look like:
input class=af_inputText p_AFHover p_AFDisabled/ and when the user
moves the mouse
away, you'd take off the hover style class using DHTML and it would be:
input class=af_inputText p_AFDisabled
You would document for the skinners the 'states' like this:
:disabled - This pseudo-class is used to style the inputText when it is
disabled af:inputText disabled='true'/
:hover - This pseudo-class is used when the user hovers over the component
And in the skin .css file the skinner can say, hey, I want the
background of the inputText to turn pink when
the user hovers over when it is disabled. He'd then write the following
skin definition:
af|inputText::content:disabled:hover {background-color:pink}
The code parses this file and creates a style class definition like this:
.af_inputText.p_AFDisabled.p_Hover {background-color:pink}
What do you think of that? :)
- Jeanne
Catalin Kormos wrote:
I don't want to say that css2 syntax would help, just trying to figure
out
if it can be possible to provide the same feature using css2 syntax.
Parsing
and generating a new css file for the browser must be done in this case
also, and merging child skin's css file with parent skin's css file. 3rd
party css2 parsers do understand our :alias, will return this as a
conditional selector, the actual name doesn't seem to have influence,
so it
will do the same for :rtl, or :ltri'm not yet sure if the :rtl pseudo
selector is used only for icons, is it?
af|inputText:disabled:read-only:active - could this be specified by the
user using 4 different class selectors? a default style with
.af-inputText, a disabled style with .af-inputText-disabled, a
read-only
style with .af-inputText-readOnly and a active style with
.af-inputText-active? the component can have only one of those
states at
one time, right? i would appreciate it if you could explain to me this a
little bit more, what is taken from the user and what is rendered in the
final css.
Thanks,
Catalin
On 6/19/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Catalin Kormos wrote:
Thanks for bringing the use of CSS3 syntax into discussion, this was
one of
the things that put me a lot into thinking actualy :). From what i can
tell,
all the features you mentioned can be achieved with CSS2 syntax too.
Here is
how i'm imagining to make this work:
- selector inclusion with :alias, this one marks any selector that is
only
a place holder for common style properties. This is alright by CSS2
syntax
too (a standard parser will return it), and all selectors that end
with
:alias are actualy removed from the final CSS, their content beeing
included
in other selectors. The inclusion by another selector will look like
this :
content:url(.bgColor:alias), this beeing the current solution,
but not
100% sure about it yet.
- right-to-left support, this is achieved by using :rtl pseudo
selector,
right? this one can get used from the beginning with another naming
strategy, like component selector name ending with -rtl.
How is this better than :rtl?
- skinning icons, all selectors names that define an icon, end with
Icon or
-icon, right? so these can be easily identified when parsing, and they
will
be removed from the final CSS, and the image url used to get the right
icon
instance.
This is what we are doing now.
- abstracting out the html/styleClass implementation, maybe i
didn't get
this right, but isn't the component making the decision which selector
to
use depending on its state? it could end up looking like
af-inputText-disabled and af-inputText.
This can get difficult when there are multiple states a component can be
in,
like disabled, readOnly, active, etc. The user can specify this with
pseudo-classes like this:
af|inputText:disabled:read-only:active. We render input
class=af_inputText p_AFDisabled p_AFReadOnly p_Active.
I hope this makes sense to you too :)
I do not understand how using css2 syntax would help. You still need to
parse the skin css file and generate a new css file for the browser.
I understand that you can use a 3rd party parser, since 3rd party
parsers don't understand our :alias, :rtl
pseudo-classes, is that right?
We have a stand-alone parser that uses the batik jars. We considered
using
Re: Question concerning skinning and concerning renderer engine
Hello, I'm the one that answered your OTN question. I didn't realize you were spending days and weeks of research on this! I'm sorry about that. I was told you found a different component. I'd say it is impossible to do what you want to do unless you add these image 'hooks' in base.desktop's ProcessTrainRenderer.java. You would need to muck with the rendering code to put in additional skinnable hoos like those that are there already. Then you would set those image hooks to either null images, or very basic images in the SimpleDesktopSkin. Then, you would document these hooks, like we do in the skin-selectors.xml document, and the end user (you?) can add their own images to these hooks, and make the processTrain look like the one in the 'oracle' skin. I haven't had a good look at the base ProcessTrainRenderer, so I'm not sure how hard it would be to put in the hooks that you need. The ADF Faces code is now in apache, and renamed to Trinidad. You can create an issue http://issues.apache.org/jira/browse/ADFFACES , and maybe someone can fix this issue for you. Or you could check out the code and make the contribution yourself. It would be reviewed and committed by someone with committer status. I hope this helps. Maybe you'll get additional suggestions on this forum. - Jeanne [EMAIL PROTECTED] wrote: Greetings, After some days/weeks of research done by a small group of people and the facts that we havn't found a lot of useful information, i'm turning to this dev mailing list in a hope that someone might know the information we are looking for ! The main goal is to allow a ProcessTrain component to be fully skinnable. More precisely, to make every aspect of it be aliased to a user created image. From the information gathered so far, a skinning file (the .css) permits the modification of 4 aspects (images) which are Visited / Unvisited / Active / Disabled. This was answered in the forum under the link below... from someone who's part of this mailing list =) ! (thx for that answer btw) http://forums.oracle.com/forums/thread.jspa?messageID=1290280#1290280 However, this isn't sufficient to our needs, thus we kept digging to see if the rendering engine itself could somehow be modified so the images used by it to create the visual look of the ProcessTrain could be modified. Those images (the 19 *.gif starting with the letter t) are hold in : \adf-faces-impl\src\main\resources\org\apache\myfaces\adfinternal\ui\laf\oracle\desktop\cImages While digging in the code, we ended at the Configuration.java, which is under the path : \adf-faces-impl\src\main\java\org\apache\myfaces\adfinternal\share\config\Configuration.java Clearly, from this class definition, it is possible in a way to get the URI and get the Path since both method exists. This is where we met our wall and thus bring my question that follow. Is it possible to access the information (probably a sort of collection or table array) where the intern references are kept that link the images used to render a ProcessTrain ? Or, is this rendering and aliasing of those images kept out of reach from the developper, thus, what we are trying to do, is in fact impossible currently? If someone is knowledgeable enough to answer those questions (be it only partly) any pieces of informations would help us at this point. Thanks!
Re: build pom problem
tried again after update of trinidad code, and deleted repository. Perhaps Matt and my settings.xml file is different than yours? Matthias Wessendorf wrote: yes, also 20 minutes ago (or so) I removed one of the deps. (was listed twice). can you give it again a try? -Matthias On 6/20/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I'm on 2.0.4. And I had done a clean build. Matthias, did you get a new, fresh checkout of the trinidad code? I can try one more time... Matthias Wessendorf wrote: Ok ladies and gents, I killed my complete maven2 local repo. did a mvn install in plugins did a mvn install in adf-faces and myfaces-api-1.1.2.jar (and pom) is downloaded in the desired folder $HOME/.m2/repository/org/apache/myfaces/core/myfaces-api/1.1.2/ What m2 version do you use? (just for the case) mvn -v gave me: Maven version: 2.0.4 cheers, Matthias On 6/20/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: It looks like I have no problem. will try the hard thing. killing local repo stay tuned dude. -Matthias On 6/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: Not at work ... but when I am home. In the meantime, what happens if you check out 1.1.2 and build it locally? Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 05:55 PM To: adffaces-dev@incubator.apache.org Subject: Re: build pom problem Hey dennis, can you also give this *problem* a try? Thx, Matthias On 6/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: I believe Craig had the same problem recently. ??? http://mail-archives.apache.org/mod_mbox/myfaces-dev/200606.mbox/[EMAIL PROTECTED] Dennis Byrne -Original Message- From: Matt Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 05:32 PM To: adffaces-dev@incubator.apache.org Subject: Re: build pom problem Hi Matthias, I think I'm seeing the same error as Jeanne. Are you saying that we need to modify a POM to fix it or download JARs manually? I'm starting over from a clean slate; I've deleted my .m2/repository and am building a freshly downloaded (totally clean) source folder. Thanks, Matt [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.myfaces.core:myfaces-api Reason: Error getting POM for 'org.apache.myfaces.core:myfaces-api' from the repository: Error transferring file org.apache.myfaces.core:myfaces-api:pom:1.1.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java-net (https://maven-repository.dev.java.net/nonav/repository/), central-corporate-legacy (http://bali.us.oracle.com:2020/maven), central-corporate (http://stacy27.us.oracle.com/maven2), snapshots-corporate (http://stacy27.us.oracle.com/maven2-snapshots) -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: build pom problem
It was the settings.xml file. Now that I have Matthias's, it works. Mine was missing a central-mirror repository. Thanks, Jeanne Matthias Wessendorf wrote: Well, I have that one from bali. will mail you offline. -Matthias On 6/20/06, Jeanne Waldman [EMAIL PROTECTED] wrote: tried again after update of trinidad code, and deleted repository. Perhaps Matt and my settings.xml file is different than yours? Matthias Wessendorf wrote: yes, also 20 minutes ago (or so) I removed one of the deps. (was listed twice). can you give it again a try? -Matthias On 6/20/06, Jeanne Waldman [EMAIL PROTECTED] wrote: I'm on 2.0.4. And I had done a clean build. Matthias, did you get a new, fresh checkout of the trinidad code? I can try one more time... Matthias Wessendorf wrote: Ok ladies and gents, I killed my complete maven2 local repo. did a mvn install in plugins did a mvn install in adf-faces and myfaces-api-1.1.2.jar (and pom) is downloaded in the desired folder $HOME/.m2/repository/org/apache/myfaces/core/myfaces-api/1.1.2/ What m2 version do you use? (just for the case) mvn -v gave me: Maven version: 2.0.4 cheers, Matthias On 6/20/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: It looks like I have no problem. will try the hard thing. killing local repo stay tuned dude. -Matthias On 6/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: Not at work ... but when I am home. In the meantime, what happens if you check out 1.1.2 and build it locally? Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 05:55 PM To: adffaces-dev@incubator.apache.org Subject: Re: build pom problem Hey dennis, can you also give this *problem* a try? Thx, Matthias On 6/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: I believe Craig had the same problem recently. ??? http://mail-archives.apache.org/mod_mbox/myfaces-dev/200606.mbox/[EMAIL PROTECTED] Dennis Byrne -Original Message- From: Matt Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 05:32 PM To: adffaces-dev@incubator.apache.org Subject: Re: build pom problem Hi Matthias, I think I'm seeing the same error as Jeanne. Are you saying that we need to modify a POM to fix it or download JARs manually? I'm starting over from a clean slate; I've deleted my .m2/repository and am building a freshly downloaded (totally clean) source folder. Thanks, Matt [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.myfaces.core:myfaces-api Reason: Error getting POM for 'org.apache.myfaces.core:myfaces-api' from the repository: Error transferring file org.apache.myfaces.core:myfaces-api:pom:1.1.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java-net (https://maven-repository.dev.java.net/nonav/repository/), central-corporate-legacy (http://bali.us.oracle.com:2020/maven), central-corporate (http://stacy27.us.oracle.com/maven2), snapshots-corporate (http://stacy27.us.oracle.com/maven2-snapshots) -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
