Hi,
I tried to debug the strange InputTextRenderer behaviour (in short: the
result of
my getShortDesc(FacesBean) seems to be overruled somehow) without any big
clue
where to start...
Well, I put a breakpoint in the
org.apache.myfaces.trinidad.bean.FacesBeanImpl's
method setProperty(PropertyKey key, Object value) and looked at the millions
of keys and
values. When I almost gave up, I finally saw my "original" shortDesc as
value (and
shortDesc as key...). This is what the stack looked like:
Thread [btpool0-1] (Suspended (breakpoint at line 100 in FacesBeanImpl))
UIXEditableFacesBeanImpl(FacesBeanImpl).setProperty(PropertyKey, Object)
line: 100
UIXEditableFacesBeanImpl.setProperty(PropertyKey, Object) line: 33
CoreInputText(UIXComponentBase).setProperty(PropertyKey, Object) line:
1112
CoreInputText.setShortDesc(String) line: 305
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(FaceletContext,
Object) line: 49
MetadataImpl.applyMetadata(FaceletContext, Object) line: 36
TrinidadComponentHandler(MetaTagHandler).setAttributes(FaceletContext,
Object) line: 62
TrinidadComponentHandler(ComponentHandler).apply(FaceletContext,
UIComponent) line: 144
DefineHandler.apply(FaceletContext, UIComponent) line: 58
CompositionHandler.apply(FaceletContext, UIComponent, String) line: 128
DefaultFaceletContext$TemplateManager.apply(FaceletContext, UIComponent,
String) line: 306
DefaultFaceletContext.includeDefinition(UIComponent, String) line: 279
InsertHandler.apply(FaceletContext, UIComponent) line: 68
CompositeFaceletHandler.apply(FaceletContext, UIComponent) line: 47
TrinidadComponentHandler(ComponentHandler).applyNextHandler(FaceletContext,
UIComponent) line: 314
TrinidadComponentHandler(ComponentHandler).apply(FaceletContext,
UIComponent) line: 169
CompositeFaceletHandler.apply(FaceletContext, UIComponent) line: 47
TrinidadComponentHandler(ComponentHandler).applyNextHandler(FaceletContext,
UIComponent) line: 314
TrinidadComponentHandler(ComponentHandler).apply(FaceletContext,
UIComponent) line: 169
TrinidadComponentHandler(ComponentHandler).applyNextHandler(FaceletContext,
UIComponent) line: 314
TrinidadComponentHandler(ComponentHandler).apply(FaceletContext,
UIComponent) line: 169
CompositeFaceletHandler.apply(FaceletContext, UIComponent) line: 47
TrinidadComponentHandler(ComponentHandler).applyNextHandler(FaceletContext,
UIComponent) line: 314
TrinidadComponentHandler(ComponentHandler).apply(FaceletContext,
UIComponent) line: 169
NamespaceHandler.apply(FaceletContext, UIComponent) line: 49
CompositeFaceletHandler.apply(FaceletContext, UIComponent) line: 47
EncodingHandler.apply(FaceletContext, UIComponent) line: 25
DefaultFacelet.include(DefaultFaceletContext, UIComponent) line: 248
DefaultFacelet.include(DefaultFaceletContext, UIComponent, URL) line:
294
DefaultFacelet.include(DefaultFaceletContext, UIComponent, String) line:
273
DefaultFaceletContext.includeFacelet(UIComponent, String) line: 143
CompositionHandler.apply(FaceletContext, UIComponent) line: 113
NamespaceHandler.apply(FaceletContext, UIComponent) line: 49
EncodingHandler.apply(FaceletContext, UIComponent) line: 25
DefaultFacelet.apply(FacesContext, UIComponent) line: 95
FaceletViewHandler.buildView(FacesContext, UIViewRoot) line: 503
FaceletViewHandler.renderView(FacesContext, UIViewRoot) line: 546
ViewHandlerImpl.renderView(FacesContext, UIViewRoot) line: 182
RenderResponseExecutor.execute(FacesContext) line: 41
LifecycleImpl.render(FacesContext) line: 138
FacesServlet.service(ServletRequest, ServletResponse) line: 141
ServletHolder.handle(ServletRequest, ServletResponse) line: 487
ServletHandler$CachedChain.doFilter(ServletRequest, ServletResponse)
line:
1098
TrinidadFilterImpl._invokeDoFilter(ServletRequest, ServletResponse,
FilterChain) line: 241
TrinidadFilterImpl._doFilterImpl(ServletRequest, ServletResponse,
FilterChain) line: 198
TrinidadFilterImpl.doFilter(ServletRequest, ServletResponse,
FilterChain)
line: 152
TrinidadFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line:
92
ServletHandler$CachedChain.doFilter(ServletRequest, ServletResponse)
line:
1089
ServletHandler(ServletHandler).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 365
SecurityHandler.handle(String, HttpServletRequest, HttpServletResponse,
int) line: 216
SessionHandler.handle(String, HttpServletRequest, HttpServletResponse,
int)
line: 181
WebAppContext(ContextHandler).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 712
WebAppContext.handle(String, HttpServletRequest, HttpServletResponse,
int)
line: 405
ContextHandlerCollection.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 211
HandlerCollection.handle(String, HttpServletRequest,
HttpServletResponse,
int) line: 114
Server(HandlerWrapper).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 139
Server.handle(HttpConnection) line: 285
HttpConnection.handleRequest() line: 502
HttpConnection$RequestHandler.headerComplete() line: 821
HttpParser.parseNext() line: 513
HttpParser.parseAvailable() line: 208
HttpConnection.handle() line: 378
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run()
line:
368
BoundedThreadPool$PoolThread.run() line: 442
Note:
I don't know, if this is important in this context, but I forgot to say (and
you'll notice
by looking at the stack), we're working in a Facelets context.
One thing which I notice in the stack is that the CoreInputText's
setShortDesc(String) is
called. Setting a breakpoint there shows that it's just called once per
inputText instance,
setting the original shortDesc and not the "concatenated" one.
I got the impression, that this one call sets the shortDesc in the
FacesBeanImpl instance
which then somehow "wins over" my
InputTextExtRenderer.getShortDesc(FacesBean).
Am I right about this and if yes, is this the expected behaviour or is
something wrong there?
By the way, does the CoreInputText come into play via the
InputTextRenderer's constructor (shown below) or is there some other
mechanism?
public InputTextRenderer()
{
super(CoreInputText.TYPE);
}
Help would be greatly appreciated,
Carsten
Carsten Pieper wrote:
>
> Hi,
>
> as Simon adviced, I'm implementing the getXyz(FacesBean) methods now. In
> my
> new OutputTextSkinnedRenderer (extending CoreOutputTextRenderer) this
> method
> worked fine (if no tooltip is given, the value itself should be presented,
> if a tooltip
> is given, original tooltip and value should both she shown):
>
> @Override
> protected String getShortDesc(FacesBean bean)
> {
> String originalShortDesc = super.getShortDesc(bean);
> String shortDesc = null;
> String valueAsString = (String) getValue(bean);
>
> if (originalShortDesc != null && originalShortDesc.length() > 0)
> {
> shortDesc = originalShortDesc + " - Field value: " + valueAsString;
> }
> else
> {
> shortDesc = valueAsString;
> }
>
> return shortDesc;
> }
>
> The same method also works fine in OutputTextExtRenderer (extends
> OutputTextRenderer).
>
> A similar method (with slight variations as there seems to be no
> getValue(FacesBean)
> neither in InputTextRenderer nor in the rest of the hierarchy) in
> InputTextExtRenderer (extends InputTextRenderer) doesn't lead to the
> desired
> result.
>
> If a shortDesc is defined, only this and not the concatenated form is
> presented as tooltip.
> The method itself still seems to function properly, but I got the
> impression, that afterwards
> something else is called, which then resets the shortDesc to "just the
> shortDesc" :-O
>
> Any ideas?
>
> Thanks in advance,
> Carsten
>
>
>
> Carsten Pieper wrote:
>>
>> Thanks a lot for the valued advice, Simon and Martin,
>>
>> so I'll have a go at Simon's recommendation. Just a question concerning
>> your remarks
>> to my approach with pushing things into the bean: Would that approach be
>> OK,
>> if I'd tidied everything up? Something like the following (in my
>> overwritten encodeAll(...)):
>>
>> // storing old bean values, altering bean values...
>>
>> super.encodeAll(context, arc, component, bean);
>>
>> // restoring old bean values
>>
>> Well, this (incl. tidying up) is how I've been showed to do this but
>> probably I've been a little
>> careless as I've never made use of these onkeyxxx properties ...
>>
>> Best regards,
>> Carsten
>>
>>
>>
>> Martin Marinschek wrote:
>>>
>>> Just as added information: what Simon says holds true also for
>>> standard JSF (non-Trinidad components)...
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 8/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
>>>> Hello again,
>>>>
>>>> I forgot to mention another issue with pushing values in the FacesBean
>>>> inside renderer code. Assume that your styleClass attribute is set to
>>>> an EL.
>>>> If the EL returns "readOnly" during a rendering, you're going to alter
>>>> the
>>>> component attributes permanently and the JavaScript events will
>>>> continue to
>>>> return false even if the styleClass is no longer "readOnly" for further
>>>> requests.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>>
>>>> On 8/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
>>>> > Hello Carsten,
>>>> >
>>>> > You shouldn't alter the bean value in the renderer. It's not right to
>>>> do
>>>> so. Instead, you should override the various getXyz(FacesBean) method
>>>> of the
>>>> renderer. This will ensure that you safely overhaul all properties
>>>> without
>>>> pushing value strange values in the saved state.
>>>> >
>>>> > Also, since the renderer is the most complex part of component
>>>> creation,
>>>> why don't you create a new custom one like outputSkinnedText or
>>>> something?
>>>> The component can extends CoreOutputText simply using a different
>>>> renderer
>>>> type. The renderer can extends CoreOutputTextRenderer and simply use
>>>> the
>>>> following code:
>>>> >
>>>> > public OutputSkinnedRenderer extends OutputTextRenderer
>>>> > {
>>>> > public OutputSkinnedRenderer()
>>>> > {
>>>> > super(CoreOutputSkinned.TYPE);
>>>> > }
>>>> >
>>>> > public void encodeAll(FacesContext context,
>>>> > RenderingContext rc,
>>>> > UIComponent component,
>>>> > FacesBean bean) throws IOException
>>>> > {
>>>> > ResponseWriter writer = context.getResponseWriter();
>>>> >
>>>> > // Create a wrapping span
>>>> > writer.startElement("span", component);
>>>> >
>>>> > // Write our new skin selector
>>>> > renderStyleClass(context, rc, "af|outputSkinnedText");
>>>> >
>>>> > // Render the text normally
>>>> > super.encodeAll(context, rc, component, bean);
>>>> >
>>>> > // Close the wrapping span element
>>>> > writer.endElement("span");
>>>> > }
>>>> > }
>>>> >
>>>> >
>>>> >
>>>> > Regards,
>>>> >
>>>> > ~ Simon
>>>> >
>>>> > On 8/13/07, Carsten Pieper <[EMAIL PROTECTED]> wrote:
>>>> >
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > as most of you might have noticed the topic of this thread somehow
>>>> drifted
>>>> > > from
>>>> > > tr:outputText to tr:inputText...
>>>> > >
>>>> > > Anyhow, I implemented my option 2) (new styleClass "readOnly"),
>>>> which is
>>>> > > running fine except of
>>>> > > one issue (inherent to this approach with onxxx --> return false;).
>>>> If
>>>> the
>>>> > > text is getting to long
>>>> > > for my inputText it's now accessible via the mouse but not (since
>>>> the
>>>> > > onkeyxxx stuff...) via
>>>> > > the keyboard.
>>>> > >
>>>> > > If anybody is interested in this non-keyboard-only solution, here
>>>> it is:
>>>> > >
>>>> > > In CSS (just note the "nested selector"; the stuff between the
>>>> brackets
>>>> > > isn't important/belongs to you...):
>>>> > >
>>>> -----------------------------------------------------------------------------------------------------
>>>> > > .readOnly af|inputText::content{
>>>> > > -tr-rule-ref: selector(".AFTextBackground:alias");
>>>> > > -tr-rule-ref:
>>>> selector(".MyDisplayTextBorder:alias");
>>>> > > }
>>>> > >
>>>> > > Extending InputTextRenderer:
>>>> > > ----------------------------
>>>> > > package bla;
>>>> > >
>>>> > > import java.io.IOException;
>>>> > >
>>>> > > import javax.faces.component.UIComponent;
>>>> > > import javax.faces.context.FacesContext;
>>>> > >
>>>> > > import org.apache.myfaces.trinidad.bean.FacesBean;
>>>> > > import org.apache.myfaces.trinidad.bean.PropertyKey;
>>>> > > import
>>>> org.apache.myfaces.trinidad.context.RenderingContext;
>>>> > > import
>>>> > >
>>>> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputTextRenderer
>>>> ;
>>>> > >
>>>> > > public class InputTextExtRenderer extends InputTextRenderer
>>>> > > {
>>>> > >
>>>> > > public InputTextExtRenderer()
>>>> > > {
>>>> > > super();
>>>> > > }
>>>> > >
>>>> > > @Override
>>>> > > protected void findTypeConstants(FacesBean.Type type)
>>>> > > {
>>>> > > super.findTypeConstants(type);
>>>> > > _styleClassKey = type.findKey("styleClass");
>>>> > > _onkeyupKey = type.findKey("onkeyup");
>>>> > > _onkeydownKey = type.findKey("onkeydown");
>>>> > > _onkeypressKey = type.findKey("onkeypress");
>>>> > > }
>>>> > >
>>>> > > @Override
>>>> > > protected void encodeAll(FacesContext context,
>>>> > > RenderingContext arc,
>>>> > > UIComponent component,
>>>> > > FacesBean bean) throws IOException
>>>> > > {
>>>> > > String styleClass =
>>>> (String)bean.getProperty(_styleClassKey);
>>>> > > if
>>>> (READONLY_INPUT_TEXT_SELECTOR.equalsIgnoreCase(styleClass))
>>>> > > {
>>>> > > bean.setProperty(_onkeyupKey, RETURN_FALSE);
>>>> > > bean.setProperty (_onkeydownKey, RETURN_FALSE);
>>>> > > bean.setProperty(_onkeypressKey, RETURN_FALSE);
>>>> > > }
>>>> > >
>>>> > > super.encodeAll(context, arc, component, bean);
>>>> > > }
>>>> > >
>>>> > > private static String READONLY_INPUT_TEXT_SELECTOR = "readOnly";
>>>> > > private static String RETURN_FALSE = "return false;";
>>>> > >
>>>> > > private PropertyKey _styleClassKey;
>>>> > > private PropertyKey _onkeyupKey;
>>>> > > private PropertyKey _onkeydownKey;
>>>> > > private PropertyKey _onkeypressKey;
>>>> > > }
>>>> > >
>>>> > > Configuring the faces-config.xml:
>>>> > > -------------------------------
>>>> > > <renderer>
>>>> > > <component-family>
>>>> > >
>>>> org.apache.myfaces.trinidad.Input
>>>> > > </component-family>
>>>> > > <renderer-type>
>>>> > >
>>>> org.apache.myfaces.trinidad.Text
>>>> > > </renderer-type>
>>>> > > <renderer-class>
>>>> > >
>>>> de.continentale.vu.jsf.base.component.trinidad.InputTextExtRenderer
>>>> > > </renderer-class>
>>>> > > </renderer>
>>>> > >
>>>> > > Using it in the JSF page:
>>>> > > -----------------------
>>>> > > <tr:inputText label="My short inputText (styleClass: readOnly;)"
>>>> > > value="Hello inputText" contentStyle="width: 50px;"
>>>> > > styleClass="readOnly"></tr:inputText>
>>>> > >
>>>> > > Cheers, Carsten
>>>> > >
>>>> > > -
>>>> > >
>>>> > > Carsten Pieper wrote:
>>>> > > >
>>>> > > > Hi Martin,
>>>> > > >
>>>> > > > yes, that works, thank you!
>>>> > > >
>>>> > > > Some thoughts, though: Without touching the renderer this would
>>>> mean
>>>> that
>>>> > > > (as in your example) the inputText's attribute readOnly must not
>>>> be
>>>> set or
>>>> > > > else the effect of these onxxx methods returning false would be
>>>> bypassed.
>>>> > > >
>>>> > > > When chosing to extend the InputTextRenderer there are two
>>>> options (at
>>>> > > > least ;-) ):
>>>> > > >
>>>> > > > 1) If attribute readOnly (or attribute disabled; should be
>>>> treated
>>>> equally
>>>> > > > in our application, but
>>>> > > > this, of course, isn't the default...) is set to true, do this in
>>>> the
>>>> new
>>>> > > > renderer:
>>>> > > > - get rid of default readOnly-behaviour (which might be tricky to
>>>> "extract
>>>> > > > and eliminate")
>>>> > > > - set those onxxx to "return false;"
>>>> > > >
>>>> > > > 2) Alternatively, leave attribute readOnly and according
>>>> behaviour
>>>> > > > untouched. Instead,
>>>> > > > - invent a new style class (e.g. "readOnly")
>>>> > > > - in the CSS, for this style class use the same settings as for
>>>> > > > "af|inputText:disabled::content"
>>>> > > > - in the renderer, if styleClass = "readOnly" set those onxxx to
>>>> "return
>>>> > > > false;"
>>>> > > >
>>>> > > > In principle, option 1) would be my favourite solution, but due
>>>> to the
>>>> > > > intricate situation
>>>> > > > (InputTextRenderer has quite a line of ancestors...) and me being
>>>> new
>>>> to
>>>> > > > the fine art of
>>>> > > > extending Trinidad renderers, which both makes it hard to isolate
>>>> what
>>>> > > > happens where and
>>>> > > > how to replace it, I think option 2) is the way for us to go
>>>> (just
>>>> > > > injecting the new behaviour
>>>> > > > for styleClass "readOnly" and delegating everything else to
>>>> > > > InputTextRenderer seems to be
>>>> > > > a lot easier...).
>>>> > > >
>>>> > > > Best regards,
>>>> > > > Carsten
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > Martin Marinschek wrote:
>>>> > > >>
>>>> > > >> Hi Carsten,
>>>> > > >>
>>>> > > >> (for reference, I'm also posting this message in the original
>>>> thread)
>>>> > > >>
>>>> > > >> I've played around with the options a bit more, and this is what
>>>> could
>>>> > > >> work - with this you'd have an input field (and therefore
>>>> automatic
>>>> > > >> text-control by the browser), and then you could also
>>>> effectively
>>>> > > >> disable the keyboard:
>>>> > > >>
>>>> > > >> <label for="text">Textfield:</label><input
>>>> id="text" name="text"
>>>> > > >> type="text" value="irgendwas" onkeyup="return false;"
>>>> > > >> onkeydown="return false;" onkeypress="return false;" />
>>>> > > >>
>>>> > > >> regards,
>>>> > > >>
>>>> > > >> Martin
>>>> > > >>
>>>> > > >> ...
>>>> > > >>
>>>> > > >> --
>>>> > > >>
>>>> > > >> http://www.irian.at
>>>> > > >>
>>>> > > >> Your JSF powerhouse -
>>>> > > >> JSF Consulting, Development and
>>>> > > >> Courses in English and German
>>>> > > >>
>>>> > > >> Professional Support for Apache MyFaces
>>>> > > >>
>>>> > > >>
>>>> > > >
>>>> > > >
>>>> > >
>>>> > > --
>>>> > > View this message in context:
>>>> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12127815
>>>> > > Sent from the MyFaces - Users mailing list archive at Nabble.com.
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12145017
Sent from the MyFaces - Users mailing list archive at Nabble.com.