Hi,
In PrimeFaces, tab component is shared among components like tabview,
accordion, wizard and carousel so tab has no renderer as these components
render the tabs with specific markup.
PF has builtin support for dynamic tabs btw.
http://www.primefaces.org/showcase-labs/ui/tabviewModel.jsf
Ch
Can anyone explain what the private method
AbstractHtmlPanelTabbedPane#getUIComponent is doing?
In instances where it is passed a UINamingContainer or UIForm, it
iterates over the children, and ultimately returns the last child it
finds (recursively calling itself for each child). What I don't
u
Yes... i will do additional testing with xhtml strict and if they work
out I will merge the changes in.
I am glad that I finally could resolve that issue.
I will also investigate whether we can do the same for title and meta
tags, which might be vital to get up to a full head replacement simulat
Ok I just committed my code, give it a proper testing and then I guess
you can close the issue.
Werner
Am 10/13/11 10:02 AM, schrieb Werner Punz:
Yes... i will do additional testing with xhtml strict and if they work
out I will merge the changes in.
I am glad that I finally could resolve that
Ok I now have a preliminary statistics page online, so if someone wants
to do it, he can integrate it via selenium.
All which has to be done is
a) run the entire testsuite with selenium in a browser engine (please no
htmlunit, that has a fair share of bugs itself)
b) analyze the final result
[
https://issues.apache.org/jira/browse/TOBAGO-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-957.
Resolution: Duplicate
> New Component selectManyShuttle
> -
Hi
Unfortunately we can't change too much the way how
works. The reason is backward compatibility must be preserved.
But I don't believe what you're trying to do with ui:repeat can work.
Instead, you should try to use c:forEach instead ui:repeat and inside
that tag use t:panelTab:
In the most basic form, a UINamingContainer is what generates the x:
prefix in your component ids.
ie, form:something:somethingelse:_id12 has three UINamingContainers:
form, something, somethingelse.
In more technical terms, it creates a new namespace for the ids of the
components that it contain
CACHE_VIEW_ROOT in combination with the metaContainer facet
---
Key: TRINIDAD-2148
URL: https://issues.apache.org/jira/browse/TRINIDAD-2148
Project: MyFaces Trinidad
Issue Type: Bug
Gang -
I recently got wind of the following web framework performance talk
that was presented at JavaOne:
https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
I did not attend, but based on the slides it looks like the presenters
did an very thorough/systematic
I would be interested as well, especially regarding their test setup, we
basically doubled for instance our ajax performance between 2.0.4 and
the current state of affairs.
So it might be interesting to see what testsetup they were using.
From a pure memory point of view we of course have a hig
Hi
I believe probably we already did that. The biggest bottleneck we had
was that renderers did many calls to map.get(). Mojarra had an
optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
suppose with the latest code we have better numbers.
regards,
Leonardo Uribe
2011/10/13 W
Yes from what i gather one of the issues they had in the slides was the
overall page size. The question there is more along the lines what did
they count, just the rendered code, or also the includes.
I can help to reduce the size on the JSF.js side. We have some code
which is not directly acti
MyFaces assumes that the WAR is exploded and XHTML files are accessible in
filesystem
-
Key: MYFACES-3356
URL: https://issues.apache.org/jira/browse/MYFACES-3356
Proj
Actually now that I have some tests at hand, I just
coded some profiling code in.
Here are some numbers for tests which are running on both impls.
The tests have been performed at the Production stage on both impls.
The testing environments where myfaces 2.1.4-SNAPSHOT against Mojarra
2.1.2. Bot
Just to add some numbers, the rendered html seems to be roughly 10-15%
more compact on Mojarra. We did some work already by replacing our
inline oamsubmit by an externalized call which was the biggest issue,
but there seems to be still room for improvement.
Werner
Am 10/14/11 1:21 AM, schri
Hi
Note in the latest code, another performance improvement was done over
generated ids (MYFACES-3330), reducing the final size of the generated
html. Doing some tests, I notice that mojarra use a "simplified" form
to call methods on the standard jsf api, calling first a function on
"mojarra" name
17 matches
Mail list logo