You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Carsten Pieper <ca...@continentale.de> on 2007/08/10 11:08:01 UTC
[Trinidad] Skinning - no CSS selector for tr:outputText?
Hello everyone,
I have been trying to skin the tr:outputText but haven't been able to find a
fitting selector. At first, I intuitively tried af|outputText but to no
avail. I could neither find anything in the selectors' list (i.e.
the link Simon gave recently:
http://myfaces.apache.org/trinidad/skin-selectors.html
http://myfaces.apache.org/trinidad/skin-selectors.html ).
Do I miss anything or is something missing here ;-) ?
Thanks in advance,
Carsten
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12087763
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Matthias Wessendorf <ma...@apache.org>.
looks like almost all classes, that extend
InputLabelAndMessageRenderer do it like InputTextRenderer
-M
On 8/15/07, Simon Lessard <si...@gmail.com> wrote:
> Hello Carsten,
>
> Wow... you're right... JIRA issue please. It should be possible to override
> all of our renderers and failing to provide a protected constructor
> receiving a FacesBean.Type prevents that.
>
>
> Regards,
>
> ~ Simon
>
>
> On 8/15/07, Carsten Pieper <ca...@continentale.de> wrote:
> >
> > Hi,
> >
> > Simon's advice works fine with me, except...
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> >
> > I can't pass my component's Type object to the renderer superclass
> > because InputTextRenderer just has this one parameterless constructor:
> >
> > public InputTextRenderer()
> > {
> > super(CoreInputText.TYPE);
> > }
> >
> > Best regards,
> > Carsten
> >
> >
> > Adam Winer wrote:
> > >
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
> > >> Hello Carsten,
> > >>
> > >> Trinidad input components, as you most likely figured, include a label
> > >> and
> > >> its message. However, to allow maximum reuse, its renderer is splitted
> in
> > >> two. There's always the "label and message renderer", ie
> > >> InputTextRenderer
> > >> that render the layout including the label and message and also
> delegate
> > >> some work to the "field renderer" which is SimpleInputTextRenderer in
> the
> > >> case of CoreInputText component. The shortDesc attribute is rendered on
> > >> the
> > >> field part so, for your override of getShortDesc to work, you'll have
> to
> > >> also override SimpleInputTextRenderer and have your new
> > >> InputTextRenderer's
> > >> getFormInputRenderer returns your new SimpleInputTextRenderer.
> > >>
> > >> Here's a small example:
> > >>
> > >> public class MyNewInputTextRenderer extends InputTextRenderer
> > >> {
> > >> public MyNewInputTextRenderer()
> > >> {
> > >> this(MyNewInputComponent.TYPE);
> > >> }
> > >>
> > >> protected MyNewInputTextRenderer(FacesBean.Type type)
> > >> {
> > >> super(type);
> > >> }
> > >>
> > >> @Override
> > >> protected void findTypeConstants( FacesBean.Type type)
> > >> {
> > >> super.findTypeConstants(type);
> > >> simpleRenderer = new
> > >> MyNewSimpleInputTextRenderer(type);
> > >> }
> > >>
> > >> @Override
> > >> protected FormInputRenderer getFormInputRenderer()
> > >> {
> > >> return simpleRenderer;
> > >> }
> > >>
> > >> private FormInputRenderer simpleRenderer;
> > >> }
> > >>
> > >> public class MyNewSimpleInputTextRenderer extends
> SimpleInputTextRenderer
> > >> {
> > >> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
> > >> {
> > >> super(type);
> > >> }
> > >>
> > >> @Override
> > >> protected String getShortDesc(FacesBean bean)
> > >> {
> > >> return super.getShortDesc (bean) + whateverExtraInfo;
> > >> }
> > >> }
> > >>
> > >> Regads,
> > >>
> > >> ~ Simon
> > >>
> > >>
> > >>
> > >> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de > wrote:
> > >> >
> > >> > 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 < simon.lessard.3@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de >
> > >> 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 .
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12157515
> > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
Fixed on the trunk.
Regards
On 8/16/07, Carsten Pieper <ca...@continentale.de> wrote:
>
>
> > Wow... you're right... JIRA issue please.
> Done (https://issues.apache.org/jira/browse/TRINIDAD-631)
>
> Best regards,
> Carsten
>
>
> --
> View this message in context:
> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12177494
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
> Wow... you're right... JIRA issue please.
Done (https://issues.apache.org/jira/browse/TRINIDAD-631)
Best regards,
Carsten
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12177494
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
That's true, but for practical purposes we cannot pretend that people won't
make their own renderers using some features already present in
trinidad-impl since they help avoiding quite a lot of boilerplate code.
Creating a new kind of input component with a label and message is probably
the most obvious case.
~ Simon
On 8/15/07, Adam Winer <aw...@gmail.com> wrote:
>
> Strictly speaking, that's not really true... all of our renderers
> are in trinidadinternal, which means that they're not really public
> to the outside world, and their APIs can change arbitrarily from
> release to release. So there's no guarantees of subclassabililty.
>
> That said, I've got no problems adding the protected constructor,
> but anyone subclassing the renderers has to know their code
> can very well break any time they move to a newer version.
>
> -- Adam
>
>
>
> On 8/15/07, Simon Lessard <si...@gmail.com> wrote:
> > Hello Carsten,
> >
> > Wow... you're right... JIRA issue please. It should be possible to
> override
> > all of our renderers and failing to provide a protected constructor
> > receiving a FacesBean.Type prevents that.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
> > On 8/15/07, Carsten Pieper <ca...@continentale.de> wrote:
> > >
> > > Hi,
> > >
> > > Simon's advice works fine with me, except...
> > > > The critical thing, which is easy to overlook, is that you
> > > > have to pass your component's Type object to the Renderer
> > > > superclasses constructor, which is what Simon's code is doing.
> > >
> > > I can't pass my component's Type object to the renderer superclass
> > > because InputTextRenderer just has this one
> parameterless constructor:
> > >
> > > public InputTextRenderer()
> > > {
> > > super(CoreInputText.TYPE);
> > > }
> > >
> > > Best regards,
> > > Carsten
> > >
> > >
> > > Adam Winer wrote:
> > > >
> > > > The critical thing, which is easy to overlook, is that you
> > > > have to pass your component's Type object to the Renderer
> > > > superclasses constructor, which is what Simon's code is doing.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > >
> > > > On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
> > > >> Hello Carsten,
> > > >>
> > > >> Trinidad input components, as you most likely figured, include a
> label
> > > >> and
> > > >> its message. However, to allow maximum reuse, its renderer is
> splitted
> > in
> > > >> two. There's always the "label and message renderer", ie
> > > >> InputTextRenderer
> > > >> that render the layout including the label and message and also
> > delegate
> > > >> some work to the "field renderer" which is SimpleInputTextRenderer
> in
> > the
> > > >> case of CoreInputText component. The shortDesc attribute is
> rendered on
> > > >> the
> > > >> field part so, for your override of getShortDesc to work, you'll
> have
> > to
> > > >> also override SimpleInputTextRenderer and have your new
> > > >> InputTextRenderer's
> > > >> getFormInputRenderer returns your new SimpleInputTextRenderer.
> > > >>
> > > >> Here's a small example:
> > > >>
> > > >> public class MyNewInputTextRenderer extends InputTextRenderer
> > > >> {
> > > >> public MyNewInputTextRenderer()
> > > >> {
> > > >> this(MyNewInputComponent.TYPE);
> > > >> }
> > > >>
> > > >> protected MyNewInputTextRenderer(FacesBean.Type type)
> > > >> {
> > > >> super(type);
> > > >> }
> > > >>
> > > >> @Override
> > > >> protected void findTypeConstants( FacesBean.Type type)
> > > >> {
> > > >> super.findTypeConstants(type);
> > > >> simpleRenderer = new
> > > >> MyNewSimpleInputTextRenderer(type);
> > > >> }
> > > >>
> > > >> @Override
> > > >> protected FormInputRenderer getFormInputRenderer()
> > > >> {
> > > >> return simpleRenderer;
> > > >> }
> > > >>
> > > >> private FormInputRenderer simpleRenderer;
> > > >> }
> > > >>
> > > >> public class MyNewSimpleInputTextRenderer extends
> > SimpleInputTextRenderer
> > > >> {
> > > >> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
> > > >> {
> > > >> super(type);
> > > >> }
> > > >>
> > > >> @Override
> > > >> protected String getShortDesc(FacesBean bean)
> > > >> {
> > > >> return super.getShortDesc (bean) + whateverExtraInfo;
> > > >> }
> > > >> }
> > > >>
> > > >> Regads,
> > > >>
> > > >> ~ Simon
> > > >>
> > > >>
> > > >>
> > > >> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de >
> wrote:
> > > >> >
> > > >> > 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 < simon.lessard.3@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de>
> > > >> 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.
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> >
> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12157515
> > > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> > >
> > >
> >
> >
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Adam Winer <aw...@gmail.com>.
Strictly speaking, that's not really true... all of our renderers
are in trinidadinternal, which means that they're not really public
to the outside world, and their APIs can change arbitrarily from
release to release. So there's no guarantees of subclassabililty.
That said, I've got no problems adding the protected constructor,
but anyone subclassing the renderers has to know their code
can very well break any time they move to a newer version.
-- Adam
On 8/15/07, Simon Lessard <si...@gmail.com> wrote:
> Hello Carsten,
>
> Wow... you're right... JIRA issue please. It should be possible to override
> all of our renderers and failing to provide a protected constructor
> receiving a FacesBean.Type prevents that.
>
>
> Regards,
>
> ~ Simon
>
>
> On 8/15/07, Carsten Pieper <ca...@continentale.de> wrote:
> >
> > Hi,
> >
> > Simon's advice works fine with me, except...
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> >
> > I can't pass my component's Type object to the renderer superclass
> > because InputTextRenderer just has this one parameterless constructor:
> >
> > public InputTextRenderer()
> > {
> > super(CoreInputText.TYPE);
> > }
> >
> > Best regards,
> > Carsten
> >
> >
> > Adam Winer wrote:
> > >
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
> > >> Hello Carsten,
> > >>
> > >> Trinidad input components, as you most likely figured, include a label
> > >> and
> > >> its message. However, to allow maximum reuse, its renderer is splitted
> in
> > >> two. There's always the "label and message renderer", ie
> > >> InputTextRenderer
> > >> that render the layout including the label and message and also
> delegate
> > >> some work to the "field renderer" which is SimpleInputTextRenderer in
> the
> > >> case of CoreInputText component. The shortDesc attribute is rendered on
> > >> the
> > >> field part so, for your override of getShortDesc to work, you'll have
> to
> > >> also override SimpleInputTextRenderer and have your new
> > >> InputTextRenderer's
> > >> getFormInputRenderer returns your new SimpleInputTextRenderer.
> > >>
> > >> Here's a small example:
> > >>
> > >> public class MyNewInputTextRenderer extends InputTextRenderer
> > >> {
> > >> public MyNewInputTextRenderer()
> > >> {
> > >> this(MyNewInputComponent.TYPE);
> > >> }
> > >>
> > >> protected MyNewInputTextRenderer(FacesBean.Type type)
> > >> {
> > >> super(type);
> > >> }
> > >>
> > >> @Override
> > >> protected void findTypeConstants( FacesBean.Type type)
> > >> {
> > >> super.findTypeConstants(type);
> > >> simpleRenderer = new
> > >> MyNewSimpleInputTextRenderer(type);
> > >> }
> > >>
> > >> @Override
> > >> protected FormInputRenderer getFormInputRenderer()
> > >> {
> > >> return simpleRenderer;
> > >> }
> > >>
> > >> private FormInputRenderer simpleRenderer;
> > >> }
> > >>
> > >> public class MyNewSimpleInputTextRenderer extends
> SimpleInputTextRenderer
> > >> {
> > >> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
> > >> {
> > >> super(type);
> > >> }
> > >>
> > >> @Override
> > >> protected String getShortDesc(FacesBean bean)
> > >> {
> > >> return super.getShortDesc (bean) + whateverExtraInfo;
> > >> }
> > >> }
> > >>
> > >> Regads,
> > >>
> > >> ~ Simon
> > >>
> > >>
> > >>
> > >> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de > wrote:
> > >> >
> > >> > 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 < simon.lessard.3@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de >
> > >> 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 .
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12157515
> > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >
> >
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
Hello Carsten,
Wow... you're right... JIRA issue please. It should be possible to override
all of our renderers and failing to provide a protected constructor
receiving a FacesBean.Type prevents that.
Regards,
~ Simon
On 8/15/07, Carsten Pieper <ca...@continentale.de> wrote:
>
>
> Hi,
>
> Simon's advice works fine with me, except...
> > The critical thing, which is easy to overlook, is that you
> > have to pass your component's Type object to the Renderer
> > superclasses constructor, which is what Simon's code is doing.
>
> I can't pass my component's Type object to the renderer superclass
> because InputTextRenderer just has this one parameterless constructor:
>
> public InputTextRenderer()
> {
> super(CoreInputText.TYPE);
> }
>
> Best regards,
> Carsten
>
>
> Adam Winer wrote:
> >
> > The critical thing, which is easy to overlook, is that you
> > have to pass your component's Type object to the Renderer
> > superclasses constructor, which is what Simon's code is doing.
> >
> > -- Adam
> >
> >
> >
> > On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
> >> Hello Carsten,
> >>
> >> Trinidad input components, as you most likely figured, include a label
> >> and
> >> its message. However, to allow maximum reuse, its renderer is splitted
> in
> >> two. There's always the "label and message renderer", ie
> >> InputTextRenderer
> >> that render the layout including the label and message and also
> delegate
> >> some work to the "field renderer" which is SimpleInputTextRenderer in
> the
> >> case of CoreInputText component. The shortDesc attribute is rendered on
> >> the
> >> field part so, for your override of getShortDesc to work, you'll have
> to
> >> also override SimpleInputTextRenderer and have your new
> >> InputTextRenderer's
> >> getFormInputRenderer returns your new SimpleInputTextRenderer.
> >>
> >> Here's a small example:
> >>
> >> public class MyNewInputTextRenderer extends InputTextRenderer
> >> {
> >> public MyNewInputTextRenderer()
> >> {
> >> this(MyNewInputComponent.TYPE);
> >> }
> >>
> >> protected MyNewInputTextRenderer(FacesBean.Type type)
> >> {
> >> super(type);
> >> }
> >>
> >> @Override
> >> protected void findTypeConstants(FacesBean.Type type)
> >> {
> >> super.findTypeConstants(type);
> >> simpleRenderer = new
> >> MyNewSimpleInputTextRenderer(type);
> >> }
> >>
> >> @Override
> >> protected FormInputRenderer getFormInputRenderer()
> >> {
> >> return simpleRenderer;
> >> }
> >>
> >> private FormInputRenderer simpleRenderer;
> >> }
> >>
> >> public class MyNewSimpleInputTextRenderer extends
> SimpleInputTextRenderer
> >> {
> >> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
> >> {
> >> super(type);
> >> }
> >>
> >> @Override
> >> protected String getShortDesc(FacesBean bean)
> >> {
> >> return super.getShortDesc (bean) + whateverExtraInfo;
> >> }
> >> }
> >>
> >> Regads,
> >>
> >> ~ Simon
> >>
> >>
> >>
> >> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de> wrote:
> >> >
> >> > 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de >
> >> 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12157515
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
Hi,
Simon's advice works fine with me, except...
> The critical thing, which is easy to overlook, is that you
> have to pass your component's Type object to the Renderer
> superclasses constructor, which is what Simon's code is doing.
I can't pass my component's Type object to the renderer superclass
because InputTextRenderer just has this one parameterless constructor:
public InputTextRenderer()
{
super(CoreInputText.TYPE);
}
Best regards,
Carsten
Adam Winer wrote:
>
> The critical thing, which is easy to overlook, is that you
> have to pass your component's Type object to the Renderer
> superclasses constructor, which is what Simon's code is doing.
>
> -- Adam
>
>
>
> On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
>> Hello Carsten,
>>
>> Trinidad input components, as you most likely figured, include a label
>> and
>> its message. However, to allow maximum reuse, its renderer is splitted in
>> two. There's always the "label and message renderer", ie
>> InputTextRenderer
>> that render the layout including the label and message and also delegate
>> some work to the "field renderer" which is SimpleInputTextRenderer in the
>> case of CoreInputText component. The shortDesc attribute is rendered on
>> the
>> field part so, for your override of getShortDesc to work, you'll have to
>> also override SimpleInputTextRenderer and have your new
>> InputTextRenderer's
>> getFormInputRenderer returns your new SimpleInputTextRenderer.
>>
>> Here's a small example:
>>
>> public class MyNewInputTextRenderer extends InputTextRenderer
>> {
>> public MyNewInputTextRenderer()
>> {
>> this(MyNewInputComponent.TYPE);
>> }
>>
>> protected MyNewInputTextRenderer(FacesBean.Type type)
>> {
>> super(type);
>> }
>>
>> @Override
>> protected void findTypeConstants(FacesBean.Type type)
>> {
>> super.findTypeConstants(type);
>> simpleRenderer = new
>> MyNewSimpleInputTextRenderer(type);
>> }
>>
>> @Override
>> protected FormInputRenderer getFormInputRenderer()
>> {
>> return simpleRenderer;
>> }
>>
>> private FormInputRenderer simpleRenderer;
>> }
>>
>> public class MyNewSimpleInputTextRenderer extends SimpleInputTextRenderer
>> {
>> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
>> {
>> super(type);
>> }
>>
>> @Override
>> protected String getShortDesc(FacesBean bean)
>> {
>> return super.getShortDesc (bean) + whateverExtraInfo;
>> }
>> }
>>
>> Regads,
>>
>> ~ Simon
>>
>>
>>
>> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de> wrote:
>> >
>> > 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de >
>> 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.
>> >
>> >
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12157515
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
Thank you very much, Simon and Adam!
With (slowly but surely) growing insight,
Carsten
Adam Winer wrote:
>
> The critical thing, which is easy to overlook, is that you
> have to pass your component's Type object to the Renderer
> superclasses constructor, which is what Simon's code is doing.
>
> -- Adam
>
>
>
> On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
>> Hello Carsten,
>>
>> Trinidad input components, as you most likely figured, include a label
>> and
>> its message. However, to allow maximum reuse, its renderer is splitted in
>> two. There's always the "label and message renderer", ie
>> InputTextRenderer
>> that render the layout including the label and message and also delegate
>> some work to the "field renderer" which is SimpleInputTextRenderer in the
>> case of CoreInputText component. The shortDesc attribute is rendered on
>> the
>> field part so, for your override of getShortDesc to work, you'll have to
>> also override SimpleInputTextRenderer and have your new
>> InputTextRenderer's
>> getFormInputRenderer returns your new SimpleInputTextRenderer.
>>
>> Here's a small example:
>>
>> public class MyNewInputTextRenderer extends InputTextRenderer
>> {
>> public MyNewInputTextRenderer()
>> {
>> this(MyNewInputComponent.TYPE);
>> }
>>
>> protected MyNewInputTextRenderer(FacesBean.Type type)
>> {
>> super(type);
>> }
>>
>> @Override
>> protected void findTypeConstants(FacesBean.Type type)
>> {
>> super.findTypeConstants(type);
>> simpleRenderer = new
>> MyNewSimpleInputTextRenderer(type);
>> }
>>
>> @Override
>> protected FormInputRenderer getFormInputRenderer()
>> {
>> return simpleRenderer;
>> }
>>
>> private FormInputRenderer simpleRenderer;
>> }
>>
>> public class MyNewSimpleInputTextRenderer extends SimpleInputTextRenderer
>> {
>> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
>> {
>> super(type);
>> }
>>
>> @Override
>> protected String getShortDesc(FacesBean bean)
>> {
>> return super.getShortDesc (bean) + whateverExtraInfo;
>> }
>> }
>>
>> Regads,
>>
>> ~ Simon
>>
>>
>>
>> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de> wrote:
>> >
>> > 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de >
>> 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.
>> >
>> >
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12156801
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Adam Winer <aw...@gmail.com>.
The critical thing, which is easy to overlook, is that you
have to pass your component's Type object to the Renderer
superclasses constructor, which is what Simon's code is doing.
-- Adam
On 8/14/07, Simon Lessard <si...@gmail.com> wrote:
> Hello Carsten,
>
> Trinidad input components, as you most likely figured, include a label and
> its message. However, to allow maximum reuse, its renderer is splitted in
> two. There's always the "label and message renderer", ie InputTextRenderer
> that render the layout including the label and message and also delegate
> some work to the "field renderer" which is SimpleInputTextRenderer in the
> case of CoreInputText component. The shortDesc attribute is rendered on the
> field part so, for your override of getShortDesc to work, you'll have to
> also override SimpleInputTextRenderer and have your new InputTextRenderer's
> getFormInputRenderer returns your new SimpleInputTextRenderer.
>
> Here's a small example:
>
> public class MyNewInputTextRenderer extends InputTextRenderer
> {
> public MyNewInputTextRenderer()
> {
> this(MyNewInputComponent.TYPE);
> }
>
> protected MyNewInputTextRenderer(FacesBean.Type type)
> {
> super(type);
> }
>
> @Override
> protected void findTypeConstants(FacesBean.Type type)
> {
> super.findTypeConstants(type);
> simpleRenderer = new
> MyNewSimpleInputTextRenderer(type);
> }
>
> @Override
> protected FormInputRenderer getFormInputRenderer()
> {
> return simpleRenderer;
> }
>
> private FormInputRenderer simpleRenderer;
> }
>
> public class MyNewSimpleInputTextRenderer extends SimpleInputTextRenderer
> {
> public MyNewSimpleInputTextRenderer(FacesBean.Type type)
> {
> super(type);
> }
>
> @Override
> protected String getShortDesc(FacesBean bean)
> {
> return super.getShortDesc (bean) + whateverExtraInfo;
> }
> }
>
> Regads,
>
> ~ Simon
>
>
>
> On 8/14/07, Carsten Pieper < carsten.pieper@continentale.de> wrote:
> >
> > 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <carsten.pieper@continentale.de > 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.
> >
> >
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
Hello Carsten,
Trinidad input components, as you most likely figured, include a label and
its message. However, to allow maximum reuse, its renderer is splitted in
two. There's always the "label and message renderer", ie InputTextRenderer
that render the layout including the label and message and also delegate
some work to the "field renderer" which is SimpleInputTextRenderer in the
case of CoreInputText component. The shortDesc attribute is rendered on the
field part so, for your override of getShortDesc to work, you'll have to
also override SimpleInputTextRenderer and have your new InputTextRenderer's
getFormInputRenderer returns your new SimpleInputTextRenderer.
Here's a small example:
public class MyNewInputTextRenderer extends InputTextRenderer
{
public MyNewInputTextRenderer()
{
this(MyNewInputComponent.TYPE);
}
protected MyNewInputTextRenderer(FacesBean.Type type)
{
super(type);
}
@Override
protected void findTypeConstants(FacesBean.Type type)
{
super.findTypeConstants(type);
simpleRenderer = new MyNewSimpleInputTextRenderer(type);
}
@Override
protected FormInputRenderer getFormInputRenderer()
{
return simpleRenderer;
}
private FormInputRenderer simpleRenderer;
}
public class MyNewSimpleInputTextRenderer extends SimpleInputTextRenderer
{
public MyNewSimpleInputTextRenderer(FacesBean.Type type)
{
super(type);
}
@Override
protected String getShortDesc(FacesBean bean)
{
return super.getShortDesc(bean) + whateverExtraInfo;
}
}
Regads,
~ Simon
On 8/14/07, Carsten Pieper <ca...@continentale.de> wrote:
>
>
> 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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.
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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#a12142307
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Carsten,
it's not enough to just call getter - then call setter again to reset the
stuff. When you call the getter, you might also evaluate a
value-binding/expression. When you set this value afterwards (for resetting
the old value), you effectively prevent the value-binding/expression from
being evaluated again, as there is a local property value set. So you need
to make sure to reset properly... With MyFaces and tomahawk components,
you'd need to check if a value-binding is set, and if it is, you'll need to
call setMyProperty(null); to reset the situation to its old state. I'm not
sure if that will work in Trinidad, as Trinidad internally will use a map.
You'd have to check in the Trinidad-sources if this is ok.
regards,
Martin
On 8/15/07, Carsten Pieper <ca...@continentale.de> wrote:
>
>
> Thanks Martin,
>
> > This means you also need to make sure you handle the case where a
> > value-expression/binding is set.
>
> probably asking a stupid question... Won't that also be covered by the
> given
> approach?
>
> // storing old bean values, altering bean values...
>
> super.encodeAll(context, arc, component, bean);
>
> //restoring old bean values
>
> Cheers,
> Carsten
>
>
> Martin Marinschek wrote:
> >
> > Hi Carsten,
> >
> > it is ok, if you correctly restore the old values ;) This means you also
> > need to make sure you handle the case where a value-expression/binding
> is
> > set.
> >
> > regards,
> >
> > Martin
> >
> > On 8/14/07, Carsten Pieper <ca...@continentale.de> 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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#a12139094
> >> 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#a12159484
> 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
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
Thanks Martin,
> This means you also need to make sure you handle the case where a
> value-expression/binding is set.
probably asking a stupid question... Won't that also be covered by the given
approach?
// storing old bean values, altering bean values...
super.encodeAll(context, arc, component, bean);
//restoring old bean values
Cheers,
Carsten
Martin Marinschek wrote:
>
> Hi Carsten,
>
> it is ok, if you correctly restore the old values ;) This means you also
> need to make sure you handle the case where a value-expression/binding is
> set.
>
> regards,
>
> Martin
>
> On 8/14/07, Carsten Pieper <ca...@continentale.de> 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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#a12139094
>> 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#a12159484
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Carsten,
it is ok, if you correctly restore the old values ;) This means you also
need to make sure you handle the case where a value-expression/binding is
set.
regards,
Martin
On 8/14/07, Carsten Pieper <ca...@continentale.de> 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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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#a12139094
> 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
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
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 <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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#a12139094
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Martin Marinschek <ma...@gmail.com>.
Just as added information: what Simon says holds true also for
standard JSF (non-Trinidad components)...
regards,
Martin
On 8/13/07, Simon Lessard <si...@gmail.com> 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 <si...@gmail.com> 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 <ca...@continentale.de> 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
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
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 <si...@gmail.com> 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 <ca...@continentale.de> 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.
> >
> >
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Simon Lessard <si...@gmail.com>.
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 <ca...@continentale.de> 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.
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
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.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
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#a12125336
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Martin Marinschek <ma...@gmail.com>.
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
On 8/13/07, Carsten Pieper <ca...@continentale.de> wrote:
>
> Hi Martin,
>
> > Well, if you change every intended span to be on block-level, there
> > will be a huge influence on the rest of your CSS.
> er, like what? Could you elaborate on this one, please?
>
> > So I wouldn't do this for each and every text-field.
> Well, our actual status is, that we're doing it for each and every non-input
> text-field...
>
> As always, best thanks,
> Carsten
>
>
> Martin Marinschek wrote:
> >
> > Well, if you change every intended span to be on block-level, there
> > will be a huge influence on the rest of your CSS. So I wouldn't do
> > this for each and every text-field.
> >
> > @sidenote: I wonder what the markup/JS/CSS looked like for this to
> > work in CIS (your existing web-framework)? Maybe we could replicate it
> > from there?
> >
> > regards,
> >
> > Martin
> >
> > On 8/13/07, Carsten Pieper <ca...@continentale.de> wrote:
> >>
> >> Hi Adam,
> >>
> >> perhaps I should be a little more speicific:
> >>
> >> We want to be able to delimit the length of the outputText's text (so
> >> that
> >> long text's won't
> >> break our pages' layout). The way we came up to achieve this was to have
> >> something like
> >> display: block;
> >> overflow: hidden;
> >> in our CSS. Without this CSS-tweaking above, a width definition via the
> >> inlineStyle attribute
> >> has no effect (as you'll surely know; I just mention it for those of us
> >> lesser experts...).
> >> If the text now gets longer than the "inlineStylish" width, it still can
> >> be
> >> accessed
> >> by/presented to the user via the tooltip (shortDesc).
> >>
> >> Thus, we enhanced the OutputTextRenderer to be styleclass-aware and to
> >> set
> >> the tooltip
> >> accordingly (if no other tooltip is defined).
> >>
> >> Do you consider this to be contrary to the "intended spirit" of the
> >> outputText (eh, or even
> >> weird) or is this approach OK?
> >>
> >> Thanks,
> >> Carsten
> >>
> >>
> >>
> >> Adam Winer wrote:
> >> >
> >> > Generally speaking, you don't want to do this for
> >> > outputText: you want to style parent components
> >> > and/or the default font of the skin, not the outputText
> >> > itself.
> >> >
> >> > -- Adam
> >> >
> >> >
> >> > On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
> >> >>
> >> >> OK, thanks for the speedy answer!
> >> >>
> >> >> So it look's we should build our own renderer...
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121153
> >> 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#a12121648
> 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
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
Hi Martin,
> Well, if you change every intended span to be on block-level, there
> will be a huge influence on the rest of your CSS.
er, like what? Could you elaborate on this one, please?
> So I wouldn't do this for each and every text-field.
Well, our actual status is, that we're doing it for each and every non-input
text-field...
As always, best thanks,
Carsten
Martin Marinschek wrote:
>
> Well, if you change every intended span to be on block-level, there
> will be a huge influence on the rest of your CSS. So I wouldn't do
> this for each and every text-field.
>
> @sidenote: I wonder what the markup/JS/CSS looked like for this to
> work in CIS (your existing web-framework)? Maybe we could replicate it
> from there?
>
> regards,
>
> Martin
>
> On 8/13/07, Carsten Pieper <ca...@continentale.de> wrote:
>>
>> Hi Adam,
>>
>> perhaps I should be a little more speicific:
>>
>> We want to be able to delimit the length of the outputText's text (so
>> that
>> long text's won't
>> break our pages' layout). The way we came up to achieve this was to have
>> something like
>> display: block;
>> overflow: hidden;
>> in our CSS. Without this CSS-tweaking above, a width definition via the
>> inlineStyle attribute
>> has no effect (as you'll surely know; I just mention it for those of us
>> lesser experts...).
>> If the text now gets longer than the "inlineStylish" width, it still can
>> be
>> accessed
>> by/presented to the user via the tooltip (shortDesc).
>>
>> Thus, we enhanced the OutputTextRenderer to be styleclass-aware and to
>> set
>> the tooltip
>> accordingly (if no other tooltip is defined).
>>
>> Do you consider this to be contrary to the "intended spirit" of the
>> outputText (eh, or even
>> weird) or is this approach OK?
>>
>> Thanks,
>> Carsten
>>
>>
>>
>> Adam Winer wrote:
>> >
>> > Generally speaking, you don't want to do this for
>> > outputText: you want to style parent components
>> > and/or the default font of the skin, not the outputText
>> > itself.
>> >
>> > -- Adam
>> >
>> >
>> > On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
>> >>
>> >> OK, thanks for the speedy answer!
>> >>
>> >> So it look's we should build our own renderer...
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121153
>> 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#a12121648
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Martin Marinschek <ma...@gmail.com>.
Well, if you change every intended span to be on block-level, there
will be a huge influence on the rest of your CSS. So I wouldn't do
this for each and every text-field.
@sidenote: I wonder what the markup/JS/CSS looked like for this to
work in CIS (your existing web-framework)? Maybe we could replicate it
from there?
regards,
Martin
On 8/13/07, Carsten Pieper <ca...@continentale.de> wrote:
>
> Hi Adam,
>
> perhaps I should be a little more speicific:
>
> We want to be able to delimit the length of the outputText's text (so that
> long text's won't
> break our pages' layout). The way we came up to achieve this was to have
> something like
> display: block;
> overflow: hidden;
> in our CSS. Without this CSS-tweaking above, a width definition via the
> inlineStyle attribute
> has no effect (as you'll surely know; I just mention it for those of us
> lesser experts...).
> If the text now gets longer than the "inlineStylish" width, it still can be
> accessed
> by/presented to the user via the tooltip (shortDesc).
>
> Thus, we enhanced the OutputTextRenderer to be styleclass-aware and to set
> the tooltip
> accordingly (if no other tooltip is defined).
>
> Do you consider this to be contrary to the "intended spirit" of the
> outputText (eh, or even
> weird) or is this approach OK?
>
> Thanks,
> Carsten
>
>
>
> Adam Winer wrote:
> >
> > Generally speaking, you don't want to do this for
> > outputText: you want to style parent components
> > and/or the default font of the skin, not the outputText
> > itself.
> >
> > -- Adam
> >
> >
> > On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
> >>
> >> OK, thanks for the speedy answer!
> >>
> >> So it look's we should build our own renderer...
> >
>
> --
> View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121153
> 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
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
Hi Adam,
perhaps I should be a little more speicific:
We want to be able to delimit the length of the outputText's text (so that
long text's won't
break our pages' layout). The way we came up to achieve this was to have
something like
display: block;
overflow: hidden;
in our CSS. Without this CSS-tweaking above, a width definition via the
inlineStyle attribute
has no effect (as you'll surely know; I just mention it for those of us
lesser experts...).
If the text now gets longer than the "inlineStylish" width, it still can be
accessed
by/presented to the user via the tooltip (shortDesc).
Thus, we enhanced the OutputTextRenderer to be styleclass-aware and to set
the tooltip
accordingly (if no other tooltip is defined).
Do you consider this to be contrary to the "intended spirit" of the
outputText (eh, or even
weird) or is this approach OK?
Thanks,
Carsten
Adam Winer wrote:
>
> Generally speaking, you don't want to do this for
> outputText: you want to style parent components
> and/or the default font of the skin, not the outputText
> itself.
>
> -- Adam
>
>
> On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
>>
>> OK, thanks for the speedy answer!
>>
>> So it look's we should build our own renderer...
>
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121153
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Adam Winer <aw...@gmail.com>.
Generally speaking, you don't want to do this for
outputText: you want to style parent components
and/or the default font of the skin, not the outputText
itself.
-- Adam
On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
>
> OK, thanks for the speedy answer!
>
> So it look's we should build our own renderer...
>
> Best regards,
> Carsten
>
>
> Matthias Wessendorf-4 wrote:
> >
> > Hi Carsten,
> >
> > yes you are right. There are no skinning keys for the <tr:outputText>
> > component, because it is "just text". But there are inlineStyle or
> > styleClass attributes available on the TAG / COMPONENT
> >
> > -M
> >
> >
> > On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
> >>
> >> Hello everyone,
> >>
> >> I have been trying to skin the tr:outputText but haven't been able to
> >> find a
> >> fitting selector. At first, I intuitively tried af|outputText but to no
> >> avail. I could neither find anything in the selectors' list (i.e.
> >> the link Simon gave recently:
> >> http://myfaces.apache.org/trinidad/skin-selectors.html
> >> http://myfaces.apache.org/trinidad/skin-selectors.html ).
> >>
> >> Do I miss anything or is something missing here ;-) ?
> >>
> >> Thanks in advance,
> >> Carsten
> >> --
> >> View this message in context:
> >> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12087763
> >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > mail: matzew-at-apache-dot-org
> >
> >
>
> --
> View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12088392
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Carsten Pieper <ca...@continentale.de>.
OK, thanks for the speedy answer!
So it look's we should build our own renderer...
Best regards,
Carsten
Matthias Wessendorf-4 wrote:
>
> Hi Carsten,
>
> yes you are right. There are no skinning keys for the <tr:outputText>
> component, because it is "just text". But there are inlineStyle or
> styleClass attributes available on the TAG / COMPONENT
>
> -M
>
>
> On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
>>
>> Hello everyone,
>>
>> I have been trying to skin the tr:outputText but haven't been able to
>> find a
>> fitting selector. At first, I intuitively tried af|outputText but to no
>> avail. I could neither find anything in the selectors' list (i.e.
>> the link Simon gave recently:
>> http://myfaces.apache.org/trinidad/skin-selectors.html
>> http://myfaces.apache.org/trinidad/skin-selectors.html ).
>>
>> Do I miss anything or is something missing here ;-) ?
>>
>> Thanks in advance,
>> Carsten
>> --
>> View this message in context:
>> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12087763
>> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
>
>
--
View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12088392
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinning - no CSS selector for tr:outputText?
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi Carsten,
yes you are right. There are no skinning keys for the <tr:outputText>
component, because it is "just text". But there are inlineStyle or
styleClass attributes available on the TAG / COMPONENT
-M
On 8/10/07, Carsten Pieper <ca...@continentale.de> wrote:
>
> Hello everyone,
>
> I have been trying to skin the tr:outputText but haven't been able to find a
> fitting selector. At first, I intuitively tried af|outputText but to no
> avail. I could neither find anything in the selectors' list (i.e.
> the link Simon gave recently:
> http://myfaces.apache.org/trinidad/skin-selectors.html
> http://myfaces.apache.org/trinidad/skin-selectors.html ).
>
> Do I miss anything or is something missing here ;-) ?
>
> Thanks in advance,
> Carsten
> --
> View this message in context: http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12087763
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org