[jira] [Commented] (TOBAGO-1593) Markup to hide components on small displays
[ https://issues.apache.org/jira/browse/TOBAGO-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182485#comment-16182485 ] Matthias Wronka commented on TOBAGO-1593: - Thumbs up for #1 > Markup to hide components on small displays > --- > > Key: TOBAGO-1593 > URL: https://issues.apache.org/jira/browse/TOBAGO-1593 > Project: MyFaces Tobago > Issue Type: New Feature >Affects Versions: 3.0.0-alpha-5 >Reporter: Matthias Wronka > Fix For: 4.1.0 > > > On small devices, it should be possible to limit the components that are > displayed to a Minimum . E.g. tables should be limited to the most necessary > columns. This could be achieved by CSS-classes, that hide columns at certain > display-sizes. > The definition could look like: > > ... > > The "hideFrom"-value uses the same steps as the segmentLayout. Whenever the > given responsive-breakpoint is reached, the component should be hidden. > Maybe this should be a generic Argument for (almost) any component because > it´s a generic problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOBAGO-1731) Input suggest-layer misplaced in combination with (after-)facet
Matthias Wronka created TOBAGO-1731:
---
Summary: Input suggest-layer misplaced in combination with
(after-)facet
Key: TOBAGO-1731
URL: https://issues.apache.org/jira/browse/TOBAGO-1731
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 3.0.3
Reporter: Matthias Wronka
If a tc:in contains
* a tc:suggest
* a f:facet
the layer with containing the suggest-items is misplaced. It is displayed in
the upper left corner instead of relative beneath the tc:in.
{code:xml}
[jira] [Created] (TOBAGO-1727) NullPointerException in ComponentUtils
Matthias Wronka created TOBAGO-1727:
---
Summary: NullPointerException in ComponentUtils
Key: TOBAGO-1727
URL: https://issues.apache.org/jira/browse/TOBAGO-1727
Project: MyFaces Tobago
Issue Type: Bug
Reporter: Matthias Wronka
Priority: Trivial
When a valueBinding cannot be evaluated due to a NullPointer in the expression
of a tc:date-value-attribute, a NPE is thrown that makes it hard to figure out
whats the problem.
{code}
java.lang.NullPointerException
org.apache.myfaces.tobago.util.ComponentUtils.getConverter(ComponentUtils.java:822)
org.apache.myfaces.tobago.internal.component.AbstractUIDate.getPattern(AbstractUIDate.java:38)
org.apache.myfaces.tobago.internal.renderkit.renderer.DateRenderer.writeAdditionalAttributes(DateRenderer.java:55)
org.apache.myfaces.tobago.internal.renderkit.renderer.InRenderer.encodeBeginField(InRenderer.java:136)
org.apache.myfaces.tobago.internal.renderkit.renderer.DateRenderer.encodeBeginField(DateRenderer.java:70)
org.apache.myfaces.tobago.internal.renderkit.renderer.LabelLayoutRendererBase.encodeBegin(LabelLayoutRendererBase.java:65)
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:587)
org.apache.myfaces.tobago.internal.util.RenderUtils.encode(RenderUtils.java:95)
org.apache.myfaces.tobago.internal.util.RenderUtils.encode(RenderUtils.java:79)
{code}
It would be better, if the EL-Problem would be logged.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOBAGO-1667) /tobago/standard/style/tobago.min.css requested
Matthias Wronka created TOBAGO-1667: --- Summary: /tobago/standard/style/tobago.min.css requested Key: TOBAGO-1667 URL: https://issues.apache.org/jira/browse/TOBAGO-1667 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 3.0.0 Reporter: Matthias Wronka tobago-theme-standard/META-INF/tobago-config.xml includes non-existing file /tobago/standard/style/tobago.min.css -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1618) Render lang-Attribute in -Root
Matthias Wronka created TOBAGO-1618: --- Summary: Render lang-Attribute in -Root Key: TOBAGO-1618 URL: https://issues.apache.org/jira/browse/TOBAGO-1618 Project: MyFaces Tobago Issue Type: New Feature Reporter: Matthias Wronka Please render the current locale in the root-Tag. This enables the browser to support hyphenation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1593) Markup for to hide columns on small displays
Matthias Wronka created TOBAGO-1593: --- Summary: Markup for to hide columns on small displays Key: TOBAGO-1593 URL: https://issues.apache.org/jira/browse/TOBAGO-1593 Project: MyFaces Tobago Issue Type: New Feature Affects Versions: 3.0.0-alpha-5 Reporter: Matthias Wronka On small devices, tables should be limited to the most necessary columns. This could be achieved by CSS-classes, that hide columns at certain display-sizes. The definition could look like: ... The "hideFrom"-value uses the same steps as the segmentLayout. Whenever the given responsive-breakpoint is reached, the column should be hidden. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1592) Support custom width on tc:column (using auto-layout)
Matthias Wronka created TOBAGO-1592: --- Summary: Support custom width on tc:column (using auto-layout) Key: TOBAGO-1592 URL: https://issues.apache.org/jira/browse/TOBAGO-1592 Project: MyFaces Tobago Issue Type: New Feature Affects Versions: 3.0.0-alpha-5 Reporter: Matthias Wronka Priority: Minor When a is defined without "columns"-attribute, the browser takes care of setting the column-width based on the content. The result is often what you want, but sometimes one could wish for a little more influence :-) It should be possible to define a width for a column to overwrite the browser-behavior. This is useful e.g. if you have a table with select-boxes where you know (and want to limit) the width. This way a consistent look can be achieved, if similar tables are rendered more than once on a page. The definition could be set using : The renderer could render the width-attribute in the HTML-TD-Tag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1576) Commands with unauthorized method-bindins should by default not be rendered
Matthias Wronka created TOBAGO-1576: --- Summary: Commands with unauthorized method-bindins should by default not be rendered Key: TOBAGO-1576 URL: https://issues.apache.org/jira/browse/TOBAGO-1576 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Matthias Wronka Tobago inspects the @RolesAllowed-Annotations of method-bindings, which is a great feature! But I think the default-behaviour is not intuitive, as methods, that cannot be executed by the current user because of missing roles are only disabled. They should be not rendered! Why? If an action has to be secured it is related to some kind of functionality a user might not only be not allowed to execute but not even to see that it is there (thus forcing the programmers not to rely on this feature but implement the rendered-attribute themselves). Furthermore the user might ask hisself / herself what to do to execute this method (which of course is never possible because of the missing role-assignment he/she cannot control). This is not intuitive. If an an command is rendered disabled it should be a matter of state. E.g. some date cannot be validated right now, because it has not been saved yet, but in a second it will be. These are commands a user is authorized to execute but something else must be done before. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1575) ´s flexLayout is different when using
Matthias Wronka created TOBAGO-1575:
---
Summary: ´s flexLayout is different when using
Key: TOBAGO-1575
URL: https://issues.apache.org/jira/browse/TOBAGO-1575
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 3.0.0-alpha-3
Reporter: Matthias Wronka
Priority: Minor
We often rely on the embedded flexLayout of tc:in when adding a label to the
input field as in {{}}. A fixed width of 155px is
used for the label and the rest for the input-field.
However: If you add a {{}} to an input, the label gets a little
narrower than without suggest an breaks the visual alignment of multiple inputs
of a form, some with suggest and some without.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOBAGO-1574) AJAX not working from change-facet-command
Matthias Wronka created TOBAGO-1574: --- Summary: AJAX not working from change-facet-command Key: TOBAGO-1574 URL: https://issues.apache.org/jira/browse/TOBAGO-1574 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 3.0.0-alpha-3 Reporter: Matthias Wronka It seems to me, that an inside a change-facet-command does not work. A full request is executed. The effect is visible in the demo: http://www.irian.biz/tobago-example-demo-3.0.x/faces/content/30-concept/50-partial/partial.xhtml?dswid=3358 -> the "on Change"-SelectOneChoice causes a full roundtrip. In my tests it doesn´t matter if the renderedPartially-attribute of tc:command is used (as in your demo) or if an is a child of the command like -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1550) Add f:message to form-elements automatically
Matthias Wronka created TOBAGO-1550: --- Summary: Add f:message to form-elements automatically Key: TOBAGO-1550 URL: https://issues.apache.org/jira/browse/TOBAGO-1550 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka Since faces-messages are added for specific components I would prefer to render the tc:message in context of that component by default. So that for example would become -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1549) Style classes for faces-messages incompatible to bootstrap 4
Matthias Wronka created TOBAGO-1549: --- Summary: Style classes for faces-messages incompatible to bootstrap 4 Key: TOBAGO-1549 URL: https://issues.apache.org/jira/browse/TOBAGO-1549 Project: MyFaces Tobago Issue Type: Bug Components: Themes Reporter: Matthias Wronka Tobago adds css-class "has-error", bootstrap defines "has-danger". The bootstrap-css-class "has-success" is never set (even if there is an info-message for the component). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1541) Use ResourceBundles should support parameters
Matthias Wronka created TOBAGO-1541:
---
Summary: Use ResourceBundles should support parameters
Key: TOBAGO-1541
URL: https://issues.apache.org/jira/browse/TOBAGO-1541
Project: MyFaces Tobago
Issue Type: New Feature
Components: Core
Reporter: Matthias Wronka
Working with resourceBundles for i18n in JSF-Views should support parameters
for formatted messages similar to as described here:
http://www.mkyong.com/jsf2/jsf-2-0-and-resource-bundles-example/
The solution could look like this:
bundle.properties:
myStringWithParameters=Parameter 1 is {0}, parameter 2 {1}.
The output should be (surprise): "Parameter 1 is First value, parameter 2
Second value."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOBAGO-1389) Disable Hotkey-Behaviour
Matthias Wronka created TOBAGO-1389: --- Summary: Disable Hotkey-Behaviour Key: TOBAGO-1389 URL: https://issues.apache.org/jira/browse/TOBAGO-1389 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Matthias Wronka Priority: Minor Whenever a label (e.g. of a tx:in) contains a underscore (_), tobago creates a hotkey (alt + character after _) for the corresponding input-field. However, this is not always the desired behaviour e.g. for generic frontends where the labels are not controlled by the developer. I would appreciate a possibility to deactivate this feature globally. Furthermore an explicit way to configure HotKeys (e.g. via an extra-attribute) would be great. This would also enable the application to use the same hotkeys in multi-language-applications (like Ctrl+P is used for Drucken in german applications) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TOBAGO-1273) New Attribute visible or hidden for layoutet tags
Matthias Wronka created TOBAGO-1273: --- Summary: New Attribute visible or hidden for layoutet tags Key: TOBAGO-1273 URL: https://issues.apache.org/jira/browse/TOBAGO-1273 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka Priority: Minor The new attribute should be used similar to rendered=false. The difference would be, that components with rendered=false are not respected by the layoutmanager and hidden=true or visible=false components should use space in the layout. Values hold by an non-visible component should not be sent to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1251) tc:link is calculated to narrow when using auto, especially when images are used
Matthias Wronka created TOBAGO-1251: --- Summary: tc:link is calculated to narrow when using auto, especially when images are used Key: TOBAGO-1251 URL: https://issues.apache.org/jira/browse/TOBAGO-1251 Project: MyFaces Tobago Issue Type: Bug Reporter: Matthias Wronka The width-calculation of links doesn´t work correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1216) Markup for Default-Commands
Matthias Wronka created TOBAGO-1216: --- Summary: Markup for Default-Commands Key: TOBAGO-1216 URL: https://issues.apache.org/jira/browse/TOBAGO-1216 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.5.8 Reporter: Matthias Wronka In Tobago 1.0.x Default-Commands had another appearance than other commands (at least in IE) 'by magic'.This was useful, as you just knew what would happen if you press enter... Please add this functionality as a special markup for default-commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1214) SmartClose for non-modal popups
Matthias Wronka created TOBAGO-1214: --- Summary: SmartClose for non-modal popups Key: TOBAGO-1214 URL: https://issues.apache.org/jira/browse/TOBAGO-1214 Project: MyFaces Tobago Issue Type: New Feature Components: Themes Affects Versions: 1.5.7 Reporter: Matthias Wronka This feature aims to increase usability for lightweight non-modal popus. The popup should be closed automatically whenever the user clicks in the ui outside of the popup. Whether or not this SmartClose is activated could be controlled via an attribute of the popup-component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1202) Sheet-Header: Support for grouped column-headers and multiline-headers
Matthias Wronka created TOBAGO-1202: --- Summary: Sheet-Header: Support for grouped column-headers and multiline-headers Key: TOBAGO-1202 URL: https://issues.apache.org/jira/browse/TOBAGO-1202 Project: MyFaces Tobago Issue Type: New Feature Reporter: Matthias Wronka The goal ist to get more control over how the sheet header is rendered. We need to have sheets with multiline-headers combined with grouped headers for several columns. See attached screenshot for an example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1203) Sheet-Header: Support for (almost ;) ) any tc-input-component in header-cells
Matthias Wronka created TOBAGO-1203: --- Summary: Sheet-Header: Support for (almost ;) ) any tc-input-component in header-cells Key: TOBAGO-1203 URL: https://issues.apache.org/jira/browse/TOBAGO-1203 Project: MyFaces Tobago Issue Type: New Feature Reporter: Matthias Wronka The goal is to enable the sheet-header to gain more functionality. Currently we miss the possibility to create filter-options for the sheet-content. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1193) Pages are not scaled down when printed
Matthias Wronka created TOBAGO-1193: --- Summary: Pages are not scaled down when printed Key: TOBAGO-1193 URL: https://issues.apache.org/jira/browse/TOBAGO-1193 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.5.7 Reporter: Matthias Wronka In Tobago 1.0 pages were scaled down when using the browser-print-function to fit the page. In Tobago 1.5 this doesn´t work anymore. The content is cut off instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-957) New Component selectManyShuttle
New Component selectManyShuttle --- Key: TOBAGO-957 URL: https://issues.apache.org/jira/browse/TOBAGO-957 Project: MyFaces Tobago Issue Type: New Feature Reporter: Matthias Wronka As a new component we need a shuttle Control like this: http://www.irian.at/trinidad-demo/faces/components/selectManyShuttle.jspx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-775) GridLayout should support different attributes for vertical und horizontal cellSpacing
GridLayout should support different attributes for vertical und horizontal cellSpacing -- Key: TOBAGO-775 URL: https://issues.apache.org/jira/browse/TOBAGO-775 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.21 Reporter: Matthias Wronka We need the possibility to declare a different horizontal cellspacing than we need for vertical cellspacing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-773) tc:sheet should auto-sort the data according to sheetState at model-reload
tc:sheet should auto-sort the data according to sheetState at model-reload -- Key: TOBAGO-773 URL: https://issues.apache.org/jira/browse/TOBAGO-773 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka The Szenario is a page with a filter-panel and a sheet which displays the filtered data. The sheet contains sortable columns. When the filter is changed and the data reloaded the data should be displayed in the previously chosen order. By now only the sheetState-Information is preserved but the data is displayed in the order it is loaded from the database/backend. It would be nice to have an attribute like auto-sort in tc:sheet or an api to have to data sorted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-717) DatePicker: Stepping a month forward/backward results in a two-month-step, if the expected month has less days than the origin
DatePicker: Stepping a month forward/backward results in a two-month-step, if the expected month has less days than the origin -- Key: TOBAGO-717 URL: https://issues.apache.org/jira/browse/TOBAGO-717 Project: MyFaces Tobago Issue Type: Bug Reporter: Matthias Wronka Priority: Trivial Fix For: 1.0.21 If you select the 31.01. and click a month forward not February but March is selected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-315) Support for Facelets Tag ui:repeat
[
https://issues.apache.org/jira/browse/TOBAGO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636726#action_12636726
]
Matthias Wronka commented on TOBAGO-315:
I tried to use c:forEach instead. The problem seems to be, that validation does
not work correctly with c:forEach. The Validation-Error is recognized
correctly, but the submitted value is lost, so the user doesn´t see his
mistake. I think it´s because of c:forEach not beeing a component. I thought
this might work using ui:repeat.
Support for Facelets Tag ui:repeat
Key: TOBAGO-315
URL: https://issues.apache.org/jira/browse/TOBAGO-315
Project: MyFaces Tobago
Issue Type: New Feature
Components: Facelets
Affects Versions: 1.0.11
Environment: I used Tomcat 5.5 from Netbeans with Tobago 1.0.11,
Facelets 1.1.11 and MyFaces 1.1.5
Reporter: David Steinkopff
Assignee: Bernd Bohmann
-- face.xhtml ---
f:view xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui= http://java.sun.com/jsf/facelets;
xmlns:tc=http://myfaces.apache.org/tobago/component;
xmlns:tx= http://myfaces.apache.org/tobago/facelet-extension;
tc:page
ui:repeat value=#{testController.birds} var=bird
tc:out value=#{bird} /
/ui:repeat
/tc:page
/f:view
--- end ---
My configuration
web.xml, tobago-config.xml and faces-config.xml
only modified by facelets prefix xml to xhtml
give me following error message
---
An Error Occurred:
Don't find any RendererClass for facelets.ui.RepeatRenderer. Please check you
configuration.
+- Stack Trace
java.lang.RuntimeException: Don't find any RendererClass for
facelets.ui.RepeatRenderer. Please check you configuration.
at org.apache.myfaces.tobago.context.ResourceManagerImpl.getRenderer
(ResourceManagerImpl.java:399)
at
org.apache.myfaces.tobago.renderkit.TobagoRenderKit.getRenderer(TobagoRenderKit.java:61)
at
org.apache.myfaces.tobago.component.ComponentUtil.getRenderer(ComponentUtil.java:429)
at
org.apache.myfaces.tobago.component.ComponentUtil.getRenderer(ComponentUtil.java:411)
at
org.apache.myfaces.tobago.renderkit.html.HtmlRendererUtil.createCssClass(HtmlRendererUtil.java:133)
at
org.apache.myfaces.tobago.renderkit.html.HtmlRendererUtil.prepareRender
(HtmlRendererUtil.java:109)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.prepareRender(DefaultLayoutRenderer.java:40)
at org.apache.myfaces.tobago.renderkit.RenderUtil.encode
(RenderUtil.java:73)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:47)
at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent
(UILayout.java:71)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.PageRenderer.encodeEnd(PageRenderer.java:126)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:242)
at
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:239)
at com.sun.facelets.FaceletViewHandler.renderView
(FaceletViewHandler.java:580)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
at
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:368)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java
:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
[jira] Created: (TOBAGO-677) modal-mode for popups does not work properly
modal-mode for popups does not work properly Key: TOBAGO-677 URL: https://issues.apache.org/jira/browse/TOBAGO-677 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.17 Environment: Firefox, IE6 Reporter: Matthias Wronka If a popup is marked as modal, the user should be able to execute buttons and fill out form-fields. Both is not possible in IE (here also the style of links and buttons changes to disabled). In Firefox it looks better but still: form-fields cannot be filled out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-678) Markup for popups
Markup for popups - Key: TOBAGO-678 URL: https://issues.apache.org/jira/browse/TOBAGO-678 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.17 Reporter: Matthias Wronka At the moment it is not possible to assign a markup to a popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-659) Confirmdialog Disgard Changes
Confirmdialog Disgard Changes --- Key: TOBAGO-659 URL: https://issues.apache.org/jira/browse/TOBAGO-659 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka On some pages it is useful to let the user confirm, if he/she wants to disgard the changes on EditableValueHolders. We would prefer a solution, that enables us to display our own custom confirm-dialog (implemented as tobago-popup). It is neccessary to define buttons that in no way cause this dialog to be displayed (e.g. a print-button or a button that opens a new window). Furthermore there should be a possibility to define an area (form, subform), that contains the observed input-fields (to prevent the dialog of being displayed because of changes in a search field or such). Probably a client-side solution via JavaScript is the best approach because otherwise the navigationhandling needs to be adopted (display the same page or let navigation pass through) and differences between immediate and non-immediate actions can be ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-642) Problem with SheetSelection-JavaScript
Problem with SheetSelection-JavaScript
--
Key: TOBAGO-642
URL: https://issues.apache.org/jira/browse/TOBAGO-642
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.15
Reporter: Matthias Wronka
There is a problem in the JavaScript-Code, that handels the RowSelection within
a sheet. In larger sheets the index exeeds the int-range and a
NumberFormatException occurs. Apparently there is a problem with commata as
seperators:
snip
key = component.getClientId(facesContext) + SELECTED_POSTFIX;
if (requestParameterMap.containsKey(key)) {
String selected = (String) requestParameterMap.get(key);
if (LOG.isDebugEnabled()) {
LOG.debug(selected = + selected);
}
ListInteger selectedRows;
try {
selectedRows = StringUtil.parseIntegerList(selected);
} catch (NumberFormatException e) {
LOG.warn(selected, e);
selectedRows = Collections.emptyList();
}
component.getAttributes().put(
ATTR_SELECTED_LIST_STRING, selectedRows);
}
snap
[3/19/08 17:17:06:369 CET] 0e88 AjaxUtils I
org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
ajaxComponentIds = main:DokumenteSheet2
[3/19/08 17:17:06:397 CET] 0e88 AjaxUtils I
org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
ajaxComponent for main:DokumenteSheet2 = [EMAIL PROTECTED]
[3/19/08 17:17:06:416 CET] 0e88 UIDataI
org.apache.myfaces.tobago.component.UIData queueEvent queueEvent = [EMAIL
PROTECTED]
[3/19/08 17:17:06:438 CET] 0e88 SheetRenderer W
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer
decode 1357911131517,18,19,20,21,22,
java.lang.NumberFormatException: For input
string: 1357911131517
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java(Compiled
Code))
at java.lang.Integer.parseInt(Integer.java(Compiled Code))
at java.lang.Integer.init(Integer.java(Inlined Compiled
Code))
at
org.apache.myfaces.tobago.util.StringUtil.parseIntegerList(StringUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer.decode(SheetRenderer.java(Compiled
Code))
at
javax.faces.component.UIComponentBase.decode(UIComponentBase.java(Compiled
Code))
at
javax.faces.component.UIData.processDecodes(UIData.java(Compiled Code))
at
org.apache.myfaces.tobago.util.ApplyRequestValuesCallback.execute(ApplyRequestValuesCallback.java:34)
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIForm(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOnComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java(Compiled
Code))
at
[jira] Created: (TOBAGO-635) Enhance Detail-Presentation of FacesMessage-details
Enhance Detail-Presentation of FacesMessage-details --- Key: TOBAGO-635 URL: https://issues.apache.org/jira/browse/TOBAGO-635 Project: MyFaces Tobago Issue Type: Improvement Reporter: Matthias Wronka Priority: Minor MessageDetails should not only be displayed as a tooltip. The problem is, that the time it is displayed is often too short to read (and understand) the whole message. Furthermore it is difficult to print a tooltip (a usecase our customers have to communicate with the development-team). A possible solution would be to render the message-detail in a layer that is made visible by clicking a [+]-sign of a message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-627) JNDI-Problem on Websphere Application Server
JNDI-Problem on Websphere Application Server Key: TOBAGO-627 URL: https://issues.apache.org/jira/browse/TOBAGO-627 Project: MyFaces Tobago Issue Type: Bug Components: Core Environment: Websphere Application Server (at least version 6.1) Reporter: Matthias Wronka In our Logs on WAS we find several outputs like [2/21/08 17:12:16:569 CET] 0022 javaURLContex E NMSV0310E: A JNDI operation on a java: name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the java: name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on java: names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java: names. Exception stack trace: javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name tobago.ajax.contentType not found in context java:comp/env.] at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411) at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388) at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307) at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353) at org.apache.myfaces.tobago.ajax.api.AjaxResponseRenderer.init(AjaxResponseRenderer.java:74) at org.apache.myfaces.tobago.lifecycle.RenderResponseExecutor.init(RenderResponseExecutor.java:41) at org.apache.myfaces.tobago.lifecycle.TobagoLifecycle.init(TobagoLifecycle.java:65) at org.apache.myfaces.tobago.lifecycle.TobagoLifecycleFactory.init(TobagoLifecycleFactory.java:36) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:522) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:547) at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:432) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:232) und [2/21/08 17:12:16:665 CET] 0022 javaURLContex E NMSV0310E: A JNDI operation on a java: name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the java: name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on java: names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java: names. Exception stack trace: javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name uploadRepositoryPath not found in context java:comp/env.] at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411) at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388) at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307) at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353) at org.apache.myfaces.tobago.fileupload.FileUploadFacesContextFactoryImpl.init(FileUploadFacesContextFactoryImpl.java:79) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) sowie [2/21/08 17:12:16:695 CET] 0022 javaURLContex E NMSV0310E: A JNDI operation on a java: name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the java: name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on java: names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java: names. Exception stack
[jira] Created: (TOBAGO-623) Popup is not opened on a new view
Popup is not opened on a new view - Key: TOBAGO-623 URL: https://issues.apache.org/jira/browse/TOBAGO-623 Project: MyFaces Tobago Issue Type: Bug Components: Core, Facelets Affects Versions: 1.0.15 Reporter: Matthias Wronka A popup, that is controlled via the rendered attribut is not displayed on a new view. We already sent a Demo-App to Udo that can reproduce this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-531) tc:message should support a range of severities to be displayed
tc:message should support a range of severities to be displayed --- Key: TOBAGO-531 URL: https://issues.apache.org/jira/browse/TOBAGO-531 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka Priority: Minor It would be nice to be able to set the severity of messages that are displayed by the messages-tag. In this way it would be possible to display error-messages in another place than e.g. info-messages. The tag could look like this: tc:messages minSeverity=error maxSeverity=fatal / with no severity specified, always all severities are displayed (ordered by severity (1st order) and occurance (2nd order)). With just a minSeverity specified the maxSeverity is automatically set to fatal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-530) tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info)
tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) - Key: TOBAGO-530 URL: https://issues.apache.org/jira/browse/TOBAGO-530 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka By now, all messages use the style-class .tobago-validation-message -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-532) Popup Z-Index-Problem with DatePicker and InputSuggest in IE
Popup Z-Index-Problem with DatePicker and InputSuggest in IE Key: TOBAGO-532 URL: https://issues.apache.org/jira/browse/TOBAGO-532 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.12 Environment: This problem occurs (only ?!) on InternetExplorer (I checked version 6) Reporter: Matthias Wronka Priority: Critical If a popup contains a Datefield the corresponding datepicker is opend behind the popup-window. On other browsers than IE the Datepicker is rendered in the front but the modal-window-layer is rendered behind the first popup, so the first popup is not disabled. This is a little tricky as there seems to be a dependency to the way, the popup is used. This can be reproduced in your demo: http://tobago.atanion.net/tobago-example-demo/faces/reference/popup.jsp The popup opend via the menu shows the problem at once (popup is opend via popup-reference). If you open the popup via the Open button (popup is a facet of the button) the calendar first works fine. But if you than press ok (without filling the required field) the calendar is opened behind the popup. A similar problem exists with the InputSuggest-Layer for an InputField in the popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-520) Datepicker does not render time-component when associated to Timestamp
Datepicker does not render time-component when associated to Timestamp -- Key: TOBAGO-520 URL: https://issues.apache.org/jira/browse/TOBAGO-520 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.12 Reporter: Matthias Wronka The datepicker does not render the timecomponent anymore if the corresponding value-binding points to a timestamp. Instead it sets the time-portion of the timestamp to 00:00:00 when clicking ok in the datepicker (overwriting the previously set time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-497) Tree-Selection causes no submit
Tree-Selection causes no submit
---
Key: TOBAGO-497
URL: https://issues.apache.org/jira/browse/TOBAGO-497
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Reporter: Matthias Wronka
Fix For: 1.0.12
We use a tc:tree like in the following code:
tc:tree value=#{treeForm.tree} id=tree
nameReference=userObject.title idReference=userObject.id
state=#{treeForm.state} showIcons=true showJunctions=true
showRoot=true
/tc:tree
Note, that there is no extra-action-listener like in your demo. It worked fine
with an older 1.0.12_SNAPSHOT. Now, using the 1.0.12_SNAPSHOT from 22.09. there
is no submit executed when selecting a tree node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-110) After validation of a mandatory field there is no jump to the correct tab in tabGroup
[ https://issues.apache.org/jira/browse/TOBAGO-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512462 ] Matthias Wronka commented on TOBAGO-110: This issue should be extended by any kind of validation- or conversion-error and not only mandatory-fields. I agree with Bernd, that a error style for tabs with errors would be a very useful first step. After validation of a mandatory field there is no jump to the correct tab in tabGroup - Key: TOBAGO-110 URL: https://issues.apache.org/jira/browse/TOBAGO-110 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.7 Environment: Debian Linux, all browsers Reporter: Stefan Schulte If the validation of a mandatory input field fails in a tab other than the current, there is no jump to the correct tab. The user has to go through all tabs to find the one with the occured validation error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-377) Improved Tree
[ https://issues.apache.org/jira/browse/TOBAGO-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512457 ] Matthias Wronka commented on TOBAGO-377: another important feature is the ability to display individual icons per node. Improved Tree - Key: TOBAGO-377 URL: https://issues.apache.org/jira/browse/TOBAGO-377 Project: MyFaces Tobago Issue Type: New Feature Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.1.0 Features: * var attribute to access data from the model, (the normal JSF way, the current tree has it's own way) * iterator for TreeModel like DataModel for sheet * mix fix nodes with model nodes * markup support * rendering on the server for better performance, less javascript * move expand state from TreeState to arbitrary position in model ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-450) New attribute disabled for tc:tab
New attribute disabled for tc:tab - Key: TOBAGO-450 URL: https://issues.apache.org/jira/browse/TOBAGO-450 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka We want to disable a tab -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-447) Popup is not displayed using modal=false
Popup is not displayed using modal=false -- Key: TOBAGO-447 URL: https://issues.apache.org/jira/browse/TOBAGO-447 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Matthias Wronka Fix For: 1.0.12 I think the problem ist a javascript-Error, as there is no background using non-modal popus but some javascript tries to set its properties (according to Firefox Errorconsole) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-448) Allow relative position of popus
Allow relative position of popus Key: TOBAGO-448 URL: https://issues.apache.org/jira/browse/TOBAGO-448 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.12 Reporter: Matthias Wronka Currently the top and left-attribute of a popup are absolute positions. We need the possibility to set a relative position of the popup e.g. at the mouse pointer and/or relative to the component the popup is a facet from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-441) Configuration whether to use the styles from all themes or not
[
https://issues.apache.org/jira/browse/TOBAGO-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512404
]
Matthias Wronka commented on TOBAGO-441:
As far as I know there is a difference as overwriting styles is not done
overwriting a style class but overwriting a specific attribute. An example:
Theme 1 defines
.someClass {
border: 1px solid black;
}
Theme 2 defines
.someClass {
color: red;
}
The author of theme 2 is wondering why there is a border as he only set the
color to red. Furthermore overwriting style-classes can be tricky as the most
specific style is used. Another Example:
Theme 1 defines
div.anotherClass {
padding-top: 5px;
}
Theme 2 defines
.anotherClass {
padding: 10px;
}
In that case a div that has the style-class anotherClass applied would have a
left-, right- and bottom-padding of 10px and a top-padding of 5px.
All this makes the design of Themes that want to renderers of other thems but
not the existing-style-definitions a try and error-work.
Configuration whether to use the styles from all themes or not
--
Key: TOBAGO-441
URL: https://issues.apache.org/jira/browse/TOBAGO-441
Project: MyFaces Tobago
Issue Type: New Feature
Components: Core
Affects Versions: 1.0.11
Environment: all
Reporter: Matthias Wronka
Priority: Minor
The development of css-files is very complex as the visual style of each
element is composed from several style-sheets. It would be nice, if you could
configure on a theme basis e.g. tobago-theme-config.properties, if the page
should use the css-files of the dependent themes or the page-renderer just
ommits the style-sheet-declarations for speyside, scarborough,
In the second case you can be sure, that only styles from your own themes css
are applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-449) Do ppelklick-Feature für das Sheet
Doppelklick-Feature für das Sheet - Key: TOBAGO-449 URL: https://issues.apache.org/jira/browse/TOBAGO-449 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka The sheet should offer a double-click-action. If a row is double-clicked, a per sheet defined action/action-listener should be called. The sheet-state needs to be notified about the event to enable the action-method/listener to recognize the events source-row. This feature is often used in Desktop-Application to implement a master-detail-relation e.g. to display a edit-form for a dataset from a table. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-445) Sheet-Cell-Border is misplaced
Sheet-Cell-Border is misplaced -- Key: TOBAGO-445 URL: https://issues.apache.org/jira/browse/TOBAGO-445 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Matthias Wronka Priority: Critical Fix For: 1.0.12 Attachments: Table-Border.jpg If you assign a border-style e.g. 1px solid to tobago-sheet-cell-td then the column-borders are not correctly positioned under the header-cell-borders. I believe this happens because the header is rendered using divs and not using th. Apparently the border of a div is renderd inside the element, the border of td is rendered outside the element and causes the cell to grow. The result looks like in the screenshot. One possible solution is to add a hint for the layoutmanager in the tobago-theme-config.properties that reduces the calculate column-width by the border-width of a cell. This fix should support the different style of the first column (maybe the first column has no border). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-441) Configuration whether to use the styles from all themes or not
Configuration whether to use the styles from all themes or not -- Key: TOBAGO-441 URL: https://issues.apache.org/jira/browse/TOBAGO-441 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.11 Environment: all Reporter: Matthias Wronka Priority: Minor The development of css-files is very complex as the visual style of each element is composed from several style-sheets. It would be nice, if you could configure on a theme basis e.g. tobago-theme-config.properties, if the page should use the css-files of the dependent themes or the page-renderer just ommits the style-sheet-declarations for speyside, scarborough, In the second case you can be sure, that only styles from your own themes css are applied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-443) Layout: Calculate fixed height for sheet according to displayed number of lines
Layout: Calculate fixed height for sheet according to displayed number of lines --- Key: TOBAGO-443 URL: https://issues.apache.org/jira/browse/TOBAGO-443 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.11 Environment: all Reporter: Matthias Wronka The layoutmanager should calculate the fixed height for a sheet according to the specified line-height. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-435) Add support for different media-styles
Add support for different media-styles
--
Key: TOBAGO-435
URL: https://issues.apache.org/jira/browse/TOBAGO-435
Project: MyFaces Tobago
Issue Type: New Feature
Components: Themes
Affects Versions: 1.0.11
Reporter: Matthias Wronka
Priority: Minor
Currently the tc:style tag does not allow the specification of a media-type
the style should be used for. As in the Scarborough PageRenderer this
media-type is hardcoded set to screen there is no way to specify print-styles
except from overwriting the renderer.
This is the Code-Fragment from PageRenderer:
// style files
for (String styleFile : page.getStyleFiles()) {
ListString styles = ResourceManagerUtil.getStyles(facesContext,
styleFile);
for (String styleString : styles) {
if (styleString.length() 0) {
writer.startElement(HtmlConstants.LINK, null);
writer.writeAttribute(HtmlAttributes.REL, stylesheet, false);
writer.writeAttribute(HtmlAttributes.HREF, styleString, false);
writer.writeAttribute(HtmlAttributes.MEDIA, screen, false);
writer.writeAttribute(HtmlAttributes.TYPE, text/css, false);
writer.endElement(HtmlConstants.LINK);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-358) Popup-Background renders wrong size in IE
[ https://issues.apache.org/jira/browse/TOBAGO-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499727 ] Matthias Wronka commented on TOBAGO-358: Hallo Volker, sorry for the late answer, but we had some trouble using the new release / snapshots because of our tc:attribute-styleClass-Problem. Since this is fixed now here is my answer: With Version 1.0.10 the problem occured even using the speyside-theme. With the current release (I tried 1.0.11-Preview) the problem is fixed. Thanks. Popup-Background renders wrong size in IE - Key: TOBAGO-358 URL: https://issues.apache.org/jira/browse/TOBAGO-358 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.10 Environment: Internet Explorer 6 Reporter: Matthias Wronka Attachments: screenshot-1.jpg If you open a popup in IE (I use version 6), the popup-background is narrower than the browser-window. Furthermore you can click on elements located on the right or bottom side. The attached screenshot shows this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-410) attribute-tag causes ClassCastException
attribute-tag causes ClassCastException --- Key: TOBAGO-410 URL: https://issues.apache.org/jira/browse/TOBAGO-410 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Matthias Wronka Fix For: 1.0.11, 1.0.12 We use the tc:attribute-Tag to assign styles to components such as tc:panel tc:attribute name=styleClass value=tobago-panel-default my-style / ... or using Java Code: ivPanel = (UIPanel) ComponentUtil.createComponent(facesContext, UIPanel.COMPONENT_TYPE, Panel); Map lvAttr = ivPanel.getAttributes(); lvAttr.put(styleClass, tobago-panel-default my-style); In the current snapshots this causes a ClassCastException: java.lang.ClassCastException at org.apache.myfaces.tobago.renderkit.html.StyleClasses.ensureStyleClasses(StyleClasses.java:64) at org.apache.myfaces.tobago.renderkit.html.HtmlRendererUtil.createCssClass(HtmlRendererUtil.java:115) at org.apache.myfaces.tobago.renderkit.html.HtmlRendererUtil.prepareRender(HtmlRendererUtil.java:90) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.prepareRender(DefaultLayoutRenderer.java:40) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:73) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:364) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:277) at org.apache.myfaces.tobago.component.UIPanelBase.encodeChildren(UIPanelBase.java:43) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:47) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:71) at org.apache.myfaces.tobago.component.UIPanelBase.encodeChildren(UIPanelBase.java:43) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:77) As this feature worked fine with version 1.0.10 we would appreciate a transition period, in which the styles are still assigned but a warning is logged. Currently our applications cannot use these snapshots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-411) Ommit unnecessary horizontal scrollbar
Ommit unnecessary horizontal scrollbar -- Key: TOBAGO-411 URL: https://issues.apache.org/jira/browse/TOBAGO-411 Project: MyFaces Tobago Issue Type: Wish Components: Core Affects Versions: 1.0.10 Reporter: Matthias Wronka The tree-component is rendered with a horizontal scrollbar once the vertical scrollbar is displayed even if the widest tree-element fits into the available space. It would be nice if only the vertical scrollbar was displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-399) ColumnSelector / SheetState with null-outcome
ColumnSelector / SheetState with null-outcome - Key: TOBAGO-399 URL: https://issues.apache.org/jira/browse/TOBAGO-399 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.10 Reporter: Matthias Wronka Priority: Minor In a table with a columnselector-tag we can delete rows. In the corresponding action-method we update our model and call SheetState.resetSelected(). Everything works fine, if the action-method has a non-null outcome and there is a corresponding navigation-rule. If the action-method has a null-outcome the page is reloaded and the previously deleted row is missing as expected. But in our example the first row is selected (ignoring the fact that we have reseted the SheetState). If you ommit the columnselector-tag everything works fine again (also with the null-outcome). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-396) component-height-calculation-problem
component-height-calculation-problem
Key: TOBAGO-396
URL: https://issues.apache.org/jira/browse/TOBAGO-396
Project: MyFaces Tobago
Issue Type: Bug
Reporter: Matthias Wronka
Consider the following jsp-code. It contains two panels (one in another). The
inner panel contains 4 rows of which the two in the middle are set to
rendered=false.
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tobago/component; prefix=tc%
%@ taglib uri=http://myfaces.apache.org/tobago/extension; prefix=tx%
f:view
tc:page id=edit state=#{screenSizeBean}
width=#{screenSizeBean.clientWidth}
height=#{screenSizeBean.clientHeight}
label=#{appBundle.application}
%-- content --%
tc:panel
f:facet name=layout
tc:gridLayout columns=* rows=*
margin=10px border=0/
/f:facet
tc:box label=Detailansicht
f:facet name=layout
tc:gridLayout rows=fixed;*
border=0/
/f:facet
tc:panel
f:facet name=layout
tc:gridLayout
rows=fixed;fixed;fixed;fixed columns=2*;60px;3*;40px border=0 /
/f:facet
%-- row 1 --%
tx:in value=12 required=false
readonly=true label=Zeile 1 tip=Bereitstellungszinsen markup=number
/tx:in
tc:label value=% /
tx:in value=12.10.2006
required=false readonly=true label=Bereitstellungszinsen ab
tip=Bereitstellungszinsen ab/
tc:cell/
%-- row 2 --%
tx:in value=12 required=false
readonly=true label=Zeile 2 rendered=false markup=number
f:validateLength
maximum=3 /
f:validateLongRange
minimum=0/
/tx:in
tc:label value=Mon.
rendered=false/
tc:cell spanX=2 rendered=false/
%-- row 3 --%
tx:in value=12 required=false
readonly=true label=Zeile 3 rendered=false markup=number
f:validateLength
maximum=3 /
f:validateLongRange
minimum=0/
/tx:in
tc:label value=Mon.
rendered=false/
tc:cell spanX=2 rendered=false/
%-- row 4 --%
tx:in value=12 required=false
readonly=true label=Zeile 4 tip=Bereitstellungszinsen markup=number
/tx:in
tc:label value=% /
tx:in value=12.11.2006
required=false readonly=true label=Bereitstellungszinsen ab
tip=Bereitstellungszinsen ab/
tc:cell/
/tc:panel
tc:cell/
/tc:box
/tc:panel
/tc:page
/f:view
The resulting output cuts off the lower half of the fourth row (see sreenshot).
If you change the layout-definition of the inner panel to
f:facet name=layout
tc:gridLayout rows=20px;fixed;fixed;fixed columns=2*;60px;3*;40px
border=0 /
/f:facet
Everything looks fine (see other screenshot). The interesting thing is, that
our theme defines Tobago.fixedHeight=20 in tobago-theme-config.properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-358) Popup-Background renders wrong size in IE
Popup-Background renders wrong size in IE - Key: TOBAGO-358 URL: https://issues.apache.org/jira/browse/TOBAGO-358 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.10 Environment: Internet Explorer 6 Reporter: Matthias Wronka If you open a popup in IE (I use version 6), the popup-background is narrower than the browser-window. Furthermore you can click on elements located on the right or bottom side. The attached screenshot shows this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-342) Default-Command does not invoke progress-bar
Default-Command does not invoke progress-bar Key: TOBAGO-342 URL: https://issues.apache.org/jira/browse/TOBAGO-342 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.10 Environment: All Reporter: Matthias Wronka A button, that is defined as default-command is rendered as button type=submit. So the javascript Tobago.submitAction is not used and thus the transition-attribute is not set / used. The effect is, that a default-command invokes no progress-bar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-338) tc:label ommits linefeet
tc:label ommits linefeet -- Key: TOBAGO-338 URL: https://issues.apache.org/jira/browse/TOBAGO-338 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.10 Environment: Windows, IE 6/Firefox 2, Tomcat 5.5 Reporter: Matthias Wronka Priority: Minor With version 1.0.9 a label a long label was rendered in two lines. With 1.0.10 the same label is rendered in a single line an therefor the end of the label is cut off. Sample Code: tc:panel f:facet name=layout tc:gridLayout columns=170px;1* rows=50px border=0 / /f:facet tc:cell tc:label value=Very very very very long label that is very long / /tc:cell /tc:panel The same code with tc:out instead of tc:label works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
