myfaces performance

Hi! I've seen a performance test which showed that the jboss serialization isnt faster in contrast to the default serialization. If this is the truth we should rework http://wiki.apache.org/myfaces/Performance a little bit as there it is shown as a performance gain. Could someone please clarify

Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]

Martin Marinschek wrote: 1.1 -- branch 1.2 Tomcat 6 -- branch 1.2 Tomcat 5.5. -- trunk +1 It might be also great to have more of those current virtual directory, say branch11 current12tc6 current12tc5 (=current too) I'd name both 1.2 current as sometimes in the future the tc6 stuff will be

Re: Command Link / Dummy Form: Status Report Please?

Hi Sean! It looks like the key guys are rather busy these days. What is the current plan and what do we do for current users? Do we need an intermediate release that addresses things in a backwards compatible way? The current tomahawk head is fixed in a way, that the dummyForm stuff is

Re: Command Link / Dummy Form: Status Report Please?

Hi! OK so the only issue with Tomahawk head is that people need to add h:form around there components right? Or - if they use myfaces-impl too - to add some text to their own faces-config.xml Do we need a new core release or is this just tomahawk only? I wont put my mother on it, but I guess

Re: Multiple SVN Branches (Was -- Re: JSF 1.2)

Hi! +1 for branching the current trunk to a core1.1 +1 for working with jsf 1.2 tc5 on the new trunk +1 to allow Stan to commit its work to a core1.2tc6 branch whatever we do with this branch, we wont loose Stans work and it will be best to have it in svn. Whenever we decide to move our focus

Re: Version of Servlet Container - Facelets

Hi! 1) TC 5.x (or other not JSP 2.1 compliant) and 3) TC 6 or Glassfish (or other JSP 2.1 compliant) TC6 after the first few stable builds. If no other technique requires ist, I am not sure if we move away from tomcat. Its also not sure if we ever move to facelets. Especially when upcoming jsf

Re: Java5 and JSF 1.2 (was Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]))

Hi! C:\projects\MyFaces1.2\jsf12tc6\coresvn info Path: . URL: https://svn.apache.org/repos/asf/myfaces/core/trunk I did my commit from jsf12tc6\core. Why would this subdirectory point to trunk? Maybe you copied the .svn directories too? Ciao, Mario

PLEASE Re: out of the licensing woods yet? please advice...

__ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- mfg Mario Ivankovits - OPS EDV Vertriebsges.m.b.H. Software Engineering Michael-Bernhard-Gasse 10, A-1120 Wien Tel.: +43-1-8938810 Fax: +43-1-8938810/3700 E-Mail: [EMAIL PROTECTED

Re: Upcoming Tomahawk Release

Hi! -fileupload or tree2 are working fine. I wonder that you found that tree2 works fine. Yesterday I reverted two commits in svn head as the tree was completely broken here. I planned to inform Sean about it, but havent found the time lately, but now its done :-) The commits were: r410269 and

Re: Upcoming Tomahawk Release

-fileupload or tree2 are working fine. I wonder that you found that tree2 works fine. Ok, I checked the release creation date and those changes where introduces before the branch. So definitely the tree is broken, even it our examples works. The problems were: usage of

Re: Upcoming Tomahawk Release

Sean, please add the following snippet to the release notes regarding how to reactive the dummyForm feature: renderer component-familyjavax.faces.Command/component-family renderer-typejavax.faces.Button/renderer-type

Re: Upcoming Tomahawk Release

Hi Sean! In the future, when there is a branch, please make your fixes on the branch instead of the trunk. If we focus on the branch and get it released then we can merge down soon enough. Ok, I reverted the patch from head and fixed it on the branch now. I have some problems to compile the

Re: svn commit: r412012 - /myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java

Hi! +String msg = Change component/tag ' + clientId + ' from javax.faces.*/h:tagName / + +to org.apache.myfaces.*/t:tagName /, or embed it in a form. This is not a bug. + + MyFaces core implementation no longer supports formless

Re: svn commit: r412012 - /myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java

Hi Sean! Yes we should have a Upgrading to Tomahawk 1.1.3 wiki. If someone writes it I will be sure to link to it in the release notes. http://wiki.apache.org/myfaces/Upgrading_to_Tomahawk_1.1.3 I changed the exception in shared accordingly. Ciao, Mario

Re: Enabling Client Side Validation

Hi! Please use some org.apache.myfaces... namespace in front of ENABLE_CLIENT_SIDE_VALIDATION What about integrate http://struts.apache.org/struts-shale/features-commons-validator.html into tomahawk? Then a simple global configuration parameter is missing, no? Ciao, Mario

Re: Enabling Client Side Validation

Hi Matthias! You mean client/server attribute? this is a no-no (search the mail archive) I know about the limitations of its current approach, but I meant to extend this library to honor a global flag too. I remember Craig isnt against such a flag - I think its just a matter of no time. To me

Re: svn commit: r412381 - /myfaces/shared/branches/2_0_2/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java

Hi Sean, myfaces/shared/branches/2_0_2/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java - throw new IllegalArgumentException(Component + clientId + must be embedded in an form); +String path =

Re: Upcoming Tomahawk Release

Yes, unhappily - I get it too: java.lang.IllegalArgumentException: Component _idJsp3 must be embedded in an form at org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.renderJavaScriptAnchorStart(HtmlLinkRendererBase.java:209) Ciao, Mario Sorry Sean, I still get this

Re: Upcoming Tomahawk Release

mmm w/ RI I get some issues. I am not sure which part of tomahawk should/will work with RI. I do not use the RI, so I might not be much of help here. Someone else with more insights? Are these new problems? Should this hold the release? Ciao, Mario

Re: [JSF 1.2] question

Yeaa, lets give him fun ;-) +1 for Doc M Mario +1 for Mr. M Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, June 8, 2006 04:05 PM To: 'MyFaces Development' Subject: Re: [JSF 1.2] question +1 on Martin. Eventuelly I'd

Re: [Vote] Release Tomahawk 1.1.3

Jo-o! This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) +1 for my vote +1 Ciao, Mario

pom.xml shared wrong version

Hi! I had to apply the following patch to be able to compile: Index: shared-tomahawk/pom.xml === --- shared-tomahawk/pom.xml (Revision 413826) +++ shared-tomahawk/pom.xml (Arbeitskopie) @@ -7,7 +7,7 @@

Re: pom.xml shared wrong version

Hi Sean, ok, thanks, Done! Ciao, Mario

Re: Components not working with the RI (after extermination of the dummyForm)

Hi! If t:commandLink is deprecated, t:commandNavigation should be deprecated too, but then we should have an alternative or a different implementation of commandNavigation. After a quick look at HtmlNavigationRenderer I think it should be possible to use delegation instead of inheritance to

Re: Welcome Wendy Catalin

Hi! A warm welcome to you both! Ciao, Mario

redirect navigation rule and request scoped data

Hi! As you might know, if you have a navigation rule with redirect / configuration you'll lose all the request scoped data like: * managed beans * messages * locale I've checked in the RedirectTrackerManager into tomahawk-sandbox which is a try to solve this problem. You have nothing else to do

Re: [VOTE] Move s:form to tomahawk

Hi! +1 However, we should adapt our form/commandLink/commandButton stuff to make its output compatible with RI real soon. Ciao, Mario

Re: redirect navigation rule and request scoped data

Hi! It would be better to have a context initialization parameter to enable this behaviour.. sometimes it is expected to drop request scoped stuff on redirects :). Yes, when I add the number of redirects configuration I'll add this too. BTW, nice idea.. Thanks! Some days ago I was thinking

Re: [continuum] BUILD FAILURE: Myfaces Nighly Build Script

Hi! /export/home/mrmaven/myfaces-nightly/tomahawk/core/src/main/java/org/apache/myfaces/component/html/util/HtmlComponentUtils.java:[63,39] getBooleanValue(javax.faces.component.UIComponent) in org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils cannot be applied to

please maven clean continuum [was: [continuum] BUILD FAILURE: Myfaces Nighly Build Script]

For some reason maven did not recreate the shared_* branches. Please issue a maven clean on continuum to fix this annoying thing. Thanks! Mario

Re: please maven clean continuum [was: [continuum] BUILD FAILURE: Myfaces Nighly Build Script]

Hey boy, Bernd changed the pom xml yea - tx a lot for this, however, I do not understand why my and others local build worked without this change - however a tree times salut to Bernd. Ciao, Mario

Re: Exception in PhaseListener RENDER_RESPONSE(6) afterPhase

Matthias Wessendorf schrieb: can you bring that to JIRA ? I think there is no need to bring this to jira as I already fixed this with the commit 398003 from 28.4.2006. Anyway Roland, good catch, though, why didnt you tried the latest source? Sorry for the inconvenience. Ciao, Mario

accessibility and dataTable

Hi! On myfaces-user there is a request to add the following to our datatable: * caption * id/headers stuff It looks like the caption thingy is fixed in JSF 1.2, though, I'll backport it to tomahawks datatable. The description about the id/header stuff can be found here:

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! 1) The class HtmlJSCookMenuRenderer tries to find the parent form searching for an UIForm component, but the Trinidad CoreForm doesn't extend UIForm. This cause the the dummyform stuff rendered in the page. 2) Using either af:form or h:form, calling addHiddenCommandParameter on

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! Okey, done. Here is the patched patch :) Ok, fine, but, wouldnt it be best to change the org.apache.myfaces.shared.util._ComponentUtils.findNestingForm to work with trinidad too and use this in HtmlJSCookMenuRenderer.java? Just an idea. Everything else looks fine to me. Ciao, Mario

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! Thank for your review Mario, No problem ;-) using findNestingForm may be good, but I don't know if it is used elsewhere. Maybe other objects rely on the component returned to be an UIForm? Could you please check this, e.g. a cast to UIForm will fail. But if this is not the case, I

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! Maybe we can do some cleanout, removing the RenderUtils.findParentForm and making SubFormRenderer and HtmlTabbedPaneRenderer use the _ComponentUtils method? What do you think about this? Yes, great work. So lets cleanup this stuff, but maybe without deleting those methods. We have

Re: JSCookMenu, dummy form and Trinidad problems

Cosma Colanicchia schrieb: Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent. Ok, I overlooked it, Sorry! 1 is in shared, so you safely can change the return type as we bundle a renamed copy of shared with tomahawk. and as 4 is also only used by the class itself it should be

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! Please correct if I'm wrong: references to shared class must be done using the shared package for classes in shared package itself, and using shared_tomahawk from the external tomahawk classes? Exactly! Ciao, Mario

Re: JSCookMenu, dummy form and Trinidad problems

Hi Cosma! About RenderUtils I'm in doubt.. I changed the return type and added the FacesContex argument, so its really a new method, I think that it is useless to mark it as deprecated.. also because it actually does a thin wrapping for the _ComponentUtils method, as it extracts the

Re: Client Validation Design Discussion

Hi Cagatay! There are two method getJsFunction() and getParams() that must be implemented by extended validators so which design seem more convenient? * Using an IClientSideValidator which will be implemented by extended validators marking them capable of doing validation at client side. or

Re: Client Validation Design Discussion

Hi Cagatay! One more discussion topic, the client validation is turned on/off via a context parameter, org.apache.myfaces.ENABLE_CLIENT_VALIDATION, Do you think validators should override this global setting via an attribute like client? client=true|false - yes, I think this will be a nice

Re: Client Validation Design Discussion

Hi! For one example, what if I download a third-party validator, and want to add client-side validation support to it? So, +1 for an interface. I dont think this is the best use-case as you still have to change the original validator code (implement the interface). To achieve this without the

Re: Client Validation Design Discussion

Hi! Also, recognize that client-side validation is only half of the picture; you also need client-side converters. Lets do this once needed. In fact, I hope Trinidad become a more integral part of MyFaces so that we can use Tomahawk and Trinidad and ... together

Re: Client Validation Design Discussion

Hi Cagatay! By the way, these validators run only at onsubmit event of the form. I've also implemented simple onkeypress validation that allows only integers to be entered when there is an integeronly converter by disabling letters, or max-min length validation when there is a length

Re: Client Validation Design Discussion

Hi Martin! Well, the thing is that a merge is way off on the timeline. And Cagatay has something right now, why not take it in? No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see it imported soon. Its just the converter stuff I was thinking about. But now I also think we

Re: Client Validation Design Discussion

TNT would be cooler :) but Nobago sounds silly :) *LOL* --- Mario

Re: Client Validation Design Discussion

But now I also think we should put our hands on the converter stuff, just, as far as I can see, in Trinidad they implemented a real client validator with getAsObject and getAsString - to say the truth, I dont sorry, I meant a real client converter

Re: Client Validation Design Discussion

Hi Adam! Hmmm ok, I understand the chained validator thing. So, even if we go the client side converter way, I would like to have a way to define the allowed characters for the input field. Maybe by adding a method like InputMask getInputMask() to the ClientConverter interface. This return

Re: [Renderers] HtmlRenderer / CoreRenderer ( and XhtmlRenderer)

Hi Matthias! I introduced three helper methods to shared's HtmlRenderer (renderId(), getClientId(), shouldRender()). These methods are taken CoreRenderer (Apache Trinidad Podling). Great! Though, why will a renderer override the resulting clientId? I figured out, that some Renderer's extend

Re: Client Validation Design Discussion

Hi Cagatay! A hot discussion we are having here, Yes, this is great :-) I think there is no new API here. Only thing needed is just a single interface. As I mentioned before most of the validators do not need any conversion before validating the input at all. This is not necessarily true.

Re: Client Validation Design Discussion

Hi! Maybe I can have a look at the ClientConverter stuff? Sure, that would be great Mario. Here is a proposal for the client converter stuff. http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/common/converter/ Once we approved

Re: [VOTE] Move s:form to tomahawk

Hi Martin! moving s:form has nothing to do with RI compatibility - we remain as compatible as before. Does this mean we ARE compatible with RI? We behave the same way as JSF-RI with our form/command* stuff? So if one uses tomahawk with JSF-RI and OUR t:form then it will work? Or do you mean

Re: [VOTE] Move s:form to tomahawk

Hi! Hi Martin! moving s:form has nothing to do with RI compatibility - we remain as compatible as before. Does this mean we ARE compatible with RI? We behave the same way as JSF-RI with our form/command* stuff? So if one uses tomahawk with JSF-RI and OUR t:form then it will work?

Re: [VOTE] Move s:form to tomahawk

Hi! I noticed that there are only some tests for components in Tomahawk. Wouldn't it be great to have a test-case as a requirement for promoting a component ? Sure, if we can decide what reasonable test cases are. I would like to see more test-cases too, but not by using mock tests. I think

Re: [VOTE] Move s:form to tomahawk

Hi Cagatay! Since not the form component itself but mainly the renderer is going to be extended and refer to the original form renderer after doing some script rendering, I guess t:form should work with RI as well. The sandbox form renderer do not use delegation, but uses inheritance. This

Re: [VOTE] Move s:form to tomahawk

Hi Cagatay! Since not the form component itself but mainly the renderer is going to be extended and refer to the original form renderer after doing some script rendering, I guess t:form should work with RI as well. After a short break where I ride my bicycle I'll come up with a different sight

Re: [VOTE] Move s:form to tomahawk

Hi Martin! I took the time to do our homework and made tomahawk and the RI fully compatible in all link/button/form related issues. I also added an example - form.jsf in the sandbox root which demonstrates this. Congratulations Martin - you tha man :-D Now, who said we didn't take

Re: [VOTE] Move s:form to tomahawk

Hi Cagatay! It would absolutely be excellent if h:form of myfaces is allowed to render the client validation scripts No, this is no option, then a JSF-RI user has no chance at all to get our stuff running. then there is no need for a t:fom or any additinal tag. Now, that Martin made MyFaces

Re: delay?

Hi Matthias! Anybody knowing about a delay to some svn-related mail-systems at apache`? I figured out a delay for myfaces and trinidad... anybody noticed something similar on struts or heard something on infra@ list ? Did you experienced it yesterday? Then the delay might result from approx

Re: [jira] Resolved: (TOMAHAWK-402) error message on popup, when using SSL

Hi! I am running into this error message on popup in an SSL environment issue with MyFaces 1.1.3. Is there a solution I can implement in my 1.1.3 environment to address this concern? The project I'm working on has called for a code freeze on the framework jars we're using, and so we're stuck

Re: [OT] javax.mail (1.4) dependency

Hi Matthias! But... why has the javax.mail 1.4 jar a dependency to activation 1.0.3 ? Its simply a requirement http://java.sun.com/products/javamail/ I already tried to use it without activation bad that wont work. As far as I remember they use it to instanciate the various provider (pop, imap,

Re: [jira] Resolved: (TOMAHAWK-402) error message on popup, when using SSL

Hi Jason! As it has been a few days since the last email I sent, I figured that I would drop you a quick note to remind you about my question below. I already answered your mail :-). Please see: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200607.mbox/[EMAIL PROTECTED] Ciao, Mario

Re: MyFaces PMC += Mario Ivankovits

Hi! Its a pleasure being here! Thanks! Mario, please subscribe to the pmc list and update your status on the site. I'll do right after my vacation - The internet connection here is a pain ;-) Ciao, Mario

Re: s:secure

Hi! h:panelGroup rendered=#{pageBean.isLoggedIn} h:panelGroup rendered=#{securityBean.isManager or securityBean.isAdmin} I know, that this will work, though, it looks like a hack (one I often used ;-) ). Having a simple secure tag will also reflect what the designer/developer wanted to do -

Re: TOMAHAWK-610 / TypedNumberConverter

Hi Mike! I hadn't noticed this before -- You added it while I was on vacation. Sneaky. :-) And after you'd already +1'd my implementation in the currencyConverter - BigDecimal storage thread. Hmmm, yes, sorry. If I remember correctly, I had a bad need for this and thought no one else already

Re: TOMAHAWK-610 / TypedNumberConverter

Hi Mike! Sounds good. I'm probably not going to get to it for another couple of weeks in any case. Ok, so maybe I manage to do it. I'll start work on tomahawk-610 before I start so that you know I am working on it. Ciao, Mario

Re: Partial Page Rendering for tomahawk

Hi Matthias! The sort of offline development. Sending offline a patch to a committer for letting him commit the stuff is to me a -1. Looks like a bypass. Do you propose to use jira as mini-incubator? I am not sure this is what it is meant for. In this case it was committed to the sandbox, no?

Re: Partial Page Rendering for tomahawk

Hi all! This is a initial commit so it is not yet well tested and there are still a lot of things to do, but if anyone wants to start playing around with it and making suggestions for improvements I would be thankful for some feedback. JFYI - I've started to try to use it in our application,

Re: clientId tag

Hi Martin! Wait a minute - will this work if the script itself is embedded in a panelGrid? I think so also dataTable you know with indexed clientId ... thats the plan, bad? Ciao, Mario

Re: clientId tag

Hi! Maybe I'm lost off track here - but panelGrid has render-Children set to true, so it will render the children itself, and the content in the script tag might show up somewhere totally different, out of sync with the other components? The f:verbatim tag works too within an panelGrid, no?

Re: Excel Export for Extended Datatable

Hi! Yeah, right. I wouldn't mind a separate module either - it's not too big an overhead. Not a big overhead? Yet another directory in our current thingy, yet another entry in our pom.xml and maybe another couple of poms for the module itself. Not to speak about the release process and testing

Re: Myfaces Wiki ComponentMaintainers

Ok, Mike told me that I was wrong to move this discussion to pmc@ and I should repost it at [EMAIL PROTECTED] Now, I dont want to rewarm this discussion, but when I reread my own post I think there are still valid points within. So - here we go: On 8/22/06, Mario Ivankovits [EMAIL PROTECTED

HtmlFocusRenderer questions

Hi! *) Any reason why the HtmlFocusRenderer imports dojo? DojoUtils.addMainInclude(facesContext, uiComponent, javascriptLocation, new DojoConfig()); DojoUtils.addRequire(facesContext, uiComponent, dojo.event.*); The only thing it do afterwards is something like

Re: RequestParamServltFilter Bug

Hi Ben! First, my apologies for the premature WIKI entry concerning the Conversation Tag. I'll be more discerning about my entries in the future. Oh - that was no problem. I just didnt know how to reach you so I thought I try through the wiki page itself. :-) I use the conversationTag with

naming of dojo components

Hi! Today I saw a new component coming in called DojoDialog and I thought: Is it really required - or the best idea - to prefix the dojo components with dojo? What if we change the technique used within an dojo component to something else (say superWebFlex - just a synonym), sure, one solution

Re: naming of dojo components

Hi Gerald! I just accepted the stuff from Thomas. You know, I dont wanted to point to a special person, just a general discussion. Sorry, that it was your committed component I used as sample ;-) So, let`s change the name to dynamicDialog? If it sufficiently describes it, sure, though, it was

Re: naming of dojo components

Hi! +1 on modal dialog As I said, my dynamic was just a wild guess, if the dialog is meant to be modal, then I am +1 on modal too. Ciao, Mario

Re: RedirectTracker -- per-request configuration?

Hi Mike! What about the possiblity of a per-request override for the behavior? Sure, one can do this by implementing its own e.g PerRequestRedirectTrackerPolicy which itself holds the ThreadLocal and delegates to the real policy then. I am not sure if we should provide every possible Policy, but

Re: Don't commit massive format changes with other changes

Hi! Mike, I am with you, though, (another question about this topic) do you know, do we have a wiki page which defines which codestyle we have to use? Currently, we really have a mixture, which isnt good too. Also I propose to create a codestyle file for at least IDEA and Eclipse - as far as I

Re: Don't commit massive format changes with other changes

Hi Martin! Oh my, I'm going under cover! This has started the single longest discussion on the mailing-list the last time ;) I hoped you already discussed it :-), and regarding to http://wiki.apache.org/myfaces/MyFaces_Developer_Notes this is the case. The decision was to use Suns Java Code

Re: Thanks to Sean and Wendy for 1.1.4 Core!

Hey! I would also like to thank Matthias, who also put a fair amount of time into getting this release out of the door. I don't normally like to waste bandwidth thanking people, but Sean and Wendy put in a tremendous amount of work getting 1.1.4 out the door over the course of several months.

Re: Developing in Intellij IDEA and the idea:idea maven plugin

Hi Martin! It would be nice to have a script (be it Ant, be it a Maven plugin or whatever) which changes the shared_tomahawk / _impl imports back to shared while developing. Or being able to configure maven in a way that it will NOT refactor the sources, instead it should simply create a shared

Re: Developing in Intellij IDEA and the idea:idea maven plugin

Hey. Or being able to configure maven in a way that it will NOT refactor the sources, instead it should simply create a shared and shared-source jar. said that, wouldn't it be possible to revert the shared_ stuff in svn at all? And refactor tomahawk and impl itself only for the release

new component submitOnEnter

Hi! What do you think about a new component which aims to do whats described here [1] It should operate in three modes: 1) as a child of an input* component (direct child) In this mode submitOnEnter will add a onkeypress handler to the input component and fires the button/link pointed to with

Re: new component submitOnEnter

Hi Bruno! and would something like submitOnKeyPress (including enter) be more general and with broader possibilities? Do you think about something which allows to configure which keyPress triggers the submit? How can such a configuration look like? 1) triggerKeys s:submitOnKeyPress

Re: svn commit: r454834 - /myfaces/core/trunk/api/src/main/java/javax/faces/convert/NumberConverter.java

Hi Matze! Author: matzew Date: Tue Oct 10 10:15:40 2006 New Revision: 454834 URL: http://svn.apache.org/viewvc?view=revrev=454834 Log: renamed German restaurants(lokale)... to locale Are you drunken again - You renamed all our restaurants ?! ;-) :-D --- Mario

dynamic table columns et al

Hi! As some of you might know I've developed Faces Freeway [1]. Well, I don't want to say that this project failed, but - beside - its hard to maintain a documentation, it is also hard to provide a nice looking, always working fully fledged simple way to the persistence framework e.g. hibernate.

Re: dynamic table columns et al

Hi! Well, I don't want to say that this project failed Forgot to mention: We already use it in our application. --- Mario

Re: dynamic table columns et al

Hi Martin! So Faces Freeway is officially declared dead? What a pity... Na, I don't think so. As I said, we use it and my boss is happy with it as it allows him to do some simple table-editing-data pages. But I often want to use just the GUI Builder without any automatic persistence in the

Re: dynamic table columns et al

Hi! So Faces Freeway is officially declared dead? What a pity... Na, I don't think so. The name of the component could also be: freewayGui Then we can reuse the logo we already have. Ciao, Mario

Re: dynamic table columns et al

I'm not sure about the name for the component - you want to reuse the logo for the component? Just an idea. We don't need to. I think it should only express what the component is about, not what it's for... Ok, so what about: dynaForm In fact, thats the class name of the component already.

sandbox15 - nightly build, continuum, examples

Hi! I've finished setting up the sandbox15 stuff. We now have working pom.xml things in there so that anyone who would like to check out the stuff is able to do a simple mvn install in there, though, I didn't add it to our main pom.xml file in tomahawk as then it is a requirement to use Java 5.0

Re: sandbox15 - nightly build, continuum, examples

Hi Wendy! I didn't add it to our main pom.xml file in tomahawk as then it is a requirement to use Java 5.0 for the whole build, which shouldn't be, should it? Profiles can be activated by JDK version. For example, from the Shale Apps pom: Ah yes, great idea! Works like a charm. Now I

Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations

Hi Arash! hey Mario, these gui builder components are great I think they may gain lots of attention is there any way I can read more about them? Nope, there is only the source and a simple example yet. If you checkout myfaces using the url [1] you'll get the sandbox15 module of tomahawk too.

Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations

Hi Arash! sorry for being impatient hehe :-) I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. Let's see how far we can go. For now I removed the persistence stuff, the master plan is

Extend HtmlInputCalendar with time input

Hi! Someone willing to extend our HtmlInputCalendar to allow to input a time? Additional attributes like: inputTime=true|false timePrecision=hours|minutes|seconds would be great! timePrecision will define the pattern: hours: HH minutes: HH:MM seconds: HH:MM:SS The missing part should be

Re: [continuum] BUILD FAILURE: Myfaces Nighly Build Script

Hi! [INFO] Building jar: /export/home/mrmaven/myfaces-nightly/tomahawk/sandbox15/core/target/tomahawk-sandbox15-1.1.5-SNAPSHOT-javadoc.jar [INFO] Preparing taglib:taglibdocjar [INFO] [taglib:taglibdoc] [INFO]

maven build error on continuum

Hi! Anyone has an idea why this is failing on continuum? [INFO] Building jar: /export/home/mrmaven/myfaces-nightly/tomahawk/sandbox15/core/target/tomahawk-sandbox15-1.1.5-SNAPSHOT-javadoc.jar [INFO] Preparing taglib:taglibdocjar [INFO] [taglib:taglibdoc] [INFO]

Re: [MyFaces 1.2] f:view, myfaces functionality not maintained anymore

Hi Martin! We will move this code into the view-handler. That's one of my tasks that I still not found the time for. I still don't get why this dummyForm stuff is that important, however, moving it to the view-handler wont work with a pre JSF 1.2, will it? Ciao, Mario

<    1   2   3   4   5   6   7   8   9   10   >