+1 Trinidad
it would be useful to have.
Regards,
Catalin
On 6/15/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
I'll start developing the @agent/@platform features very soon, like this
week/beginning of next week. I'll do the :lang/@locale after that, so I
can revisit the api later.
I'd like to give you a brief
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
,
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
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
, 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
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
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
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
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
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
:
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
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
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
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
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
[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
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
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
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
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:
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
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
, ::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
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
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
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
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:
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
This is wanted.
The second one is in a different stylesheet:
styleSheet direction=rtl
- Jeanne
Simon Lessard wrote:
Hello all,
Is that wanted?
~ Simon
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
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
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
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
::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
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
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
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
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
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
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
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
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
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
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
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:
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
, 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
. 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
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
(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
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
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
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
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
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
+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
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
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
' /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
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
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
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
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
. 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
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
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
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
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
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
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 {
, 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
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
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?
:
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
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
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
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
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
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
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
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:
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
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
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
=
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
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
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
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
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
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
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
.
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
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
.
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
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
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
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 #
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
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
1 - 100 of 102 matches
Mail list logo
