October 2013 - richfaces-dev - Jboss List Archives

RW repository general questions - issues

by Juraj Húska

Hello all, I have encounter following issues during working with RW repository. Could you please tell me which ones deserves an issue in the GitHub issue tracker ? 1. Building RW repo: No provider for "framework:jasmine"! , I had to run it with --force 2. I am wondering whether it is not viable to extract testing info from CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) into something like TESTING.md 3. CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) is IMHO missing some info about contributing process: e.g. file a issue, file PR etc., also some general encouragement for contributing. Actually I would rename CONTRIBUTION.md (https://github.com/richwidgets/richwidgets/blob/master/CONTRIBUTING.md) to TESTING.md and create new CONTRIBUTION.md {emoticon:class=jive_macro jive_emote|src=https://community.jboss.org/6.0.3.60ddddd/images/emoticons... 4. We are using Karma. Should not be there command to install it, like it is for all the required tools ? 5. We are IMHO missing a process for testing the WIDGETS. I am aware that we are creating it continually. I just wanted to point it out, that we should define some rules. Cheers Juro Posted by forums Original post: https://community.jboss.org/message/843557#843557

10 years, 5 months

4
6
0 / 0

[richfaces-dev] "Necessity for events that represents evident change of component's value (both, manually or externally)"

by Lukáš Fryč

I would like to address an issue that arose from a discussion https://issues.jboss.org/browse/RF-13180 . When one reacts on changes of value, he can use 'change' event that have defficiency coming from classic HTML <input>: - the 'change' event is fired after 'blur' event when the value changed between a focus and a subsequent blur event This means in component like <r:calendar> or <r:autocomplete>, a 'change' event is not fired when input is externally changed by selection of a value from popup, but only when a value is changed and then input is blurred. This has downside in form of a bad experience: * client-side validation is triggered when autocomplete is blurred, but it could be validated right after selection from a suggestion box * so when one want to react on changes, he need to use behavior-based (as opposed to semantically-based) events, such as 'onkeypress', 'onselect' ---- This defficiency could be solved by introducing new event: e.g. 'valuechanged' which would be defined as: * event 'valuechanged' is triggered when component's input is blurred or the value is changed externally However, this solutions has its own drawback coming from a fact, that this event must be supported by library - so e.g. common JSF components won't be supported (unless we provide a shim for them - e.g. event triggering emulation). ~ Lukas

10 years, 5 months

5
4
0 / 0

PickList based on RW questions

by Juraj Húska

Hello guys, I am in the process of reviewing the *pickList* component based on the *RW* buddy. Couple of questions have risen, and I would like to ask you which ones are relevant, thus deserves an JIRA issue. 1. default value of attributes compatibility: Should default values of attributes be the same between RF5.Alpha1 and the new components? (*ordeable* attribute is different). 2. attribute *ordeable* is missing +@Attribute(defalutValue="true")+ in the AbstractPickList.java (https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...) 3. pickList.template.xml (https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...) - there are some TODOs, should they be completed ? or JIRA is just fine. I have not found any corresponding JIRA for them. 4. Could you please consider the order of the buttons in the stack ? IMHO it is weird (*not user friendly*) to have stack in this order: remove all, remove, as the first buttons. The old version of +pickList+ had it imho in a more reasonable order: Add all, add, remove, remove all See: http://richwidgets.github.io/select/pickList.html vs http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=pickLis... RichFaces 3 has the same order I am proposing. Thanks Juro Posted by forums Original post: https://community.jboss.org/message/843555#843555

10 years, 5 months

1
0
0 / 0

OpenShift deployment "showcase-latest" is out of date

by Brian Leathem

Hello all, I noticed today that the OpenShift deployment "showcase-latest" is out of date: http://showcase-latest.richfaces.org/ We have a Jenkins job building and deploying this showcase nightly. Is that jenkins job still running? Brian

10 years, 5 months

2
1
0 / 0

[richfaces-dev] Public Jenkins view

by Pavol Pitoňák

Hi, I want to make RichFaces view on our public Jenkins useful for QE, developers and community members. In order to accomplish that, we need to minimize the number of jobs that are listed and also make sure that their names describe them. You can see more detailed description of a job when you open it. This is my proposal: following jobs build RF 4.3 git repositories and deploy snapshots to public Maven repository * richfaces-4.3-archetypes * richfaces-4.3-build * richfaces-4.3-components * richfaces-4.3-core * richfaces-4.3-dev-examples * richfaces-4.3-showcase this matrix job builds whole RichFaces 4.3 and runs unit tests with various JSF implementations (latest Mojarra, latest MyFaces and Mojarra from JBoss AS 7), I propose to use prefix richfaces-4.3 * richfaces-4.x-all these two jobs build richfaces-qa repository and deploy snapshots to private Maven repository, please help me find better names for these two * richfaces-4.3-tests * richfaces-5.0-tests this job builds whole RichFaces 5 git repository, runs unit tests, runs selected functional tests marked as smoke tests in JBoss AS 7 in PhantomJS, it publishes documentation generated from code and deploys Showcase to OpenShift (broken at the moment) * richfaces-5.0 these jobs build RF 5 git repositories and deploy snapshots to public Maven repository * richfaces-5.0-archetypes * richfaces-5.0-sandbox this job runs all RF 5 functional tests in JBoss AS 7 and Firefox, I propose to to rename it to richfaces-5.0-ftest-firefox * richfaces-5.0-firefox this job builds latest CDK and deploys it to the public Maven repository, I propose to add change prefix to richfaces-4.5 * richfaces-cdk this job builds RF 5 documentation (Developer Guide and Component Reference) and publishes it, I propose to change prefix to richfaces-5.0 * richfaces-docs This is minimal set of Jenkins jobs that we should monitor on daily basis and they should always pass (they should be blue). Thanks for your feedback. Regards, Pavol

10 years, 6 months

3
2
0 / 0

[richfaces-dev] Adding a new skinning parameter for disabled input text color

by Brian Leathem

Hello all, In seeking a resolution for RF-13099 (https://issues.jboss.org/browse/RF-13099) [1] I have come to the conclusion we need to add a new skinning parameter. Is anyone aware of the impact adding a new skinning parameter will have on existing skin extensions? Does the skinning parameter have a fallback/default value? Brian [1] https://issues.jboss.org/browse/RF-13099 Posted by forums Original post: https://community.jboss.org/message/841999#841999

10 years, 6 months

2
1
0 / 0

[richfaces-dev] In search of the best way to include RichWidgets resources in RichFaces

by richfaces-dev＠lists.jboss.org

Currently we have the RichWidgets resources included in RichFaces via a git submodule with RichWidgets storing it's compiled resources in version control to make them available for RichFaces. This is less than ideal for two reasons: 1. Storing the compiled resources in the RichWidgets "dist" folder is messy and leads to lots of merge conflicts and other superfluous commits 2. Having a submodule in RichFaces (slightly) complicates the clone and build process.* It will likely fail for most people on the first attempt. * With appropriate error messaging and docs we can however reduce the impact of this (but still a PITA) A solution to 1) is to configure maven to build the grunt resources directly. I have created RF-13123 (https://issues.jboss.org/browse/RF-13123) [A] to address this. As the first comment in that issue I posted a brief survey of the respective approaches to building the RichWidget resources. In this thread I would like to discuss an alternate approach. Consider if we drop the RichWidgets github sub-module, and instead manually copy the compiled RichWidgets files directly into the RichFaces repo (storing them there in version control). This is the same workflow we used in RichFaces 4 for including other upstream/3rd party javascript resources. Updating the RichWidgets used in RichFaces would then involve: 1. locally executing the RichWidget grunt build 2. manually copying (rsync) the dist folder into RichFaces 3. committing the updated resources into the RichFaces repo The advantages of doing this is we keep the RichFaces build to be a "pure java" maven build, and simplify the clone/build process that may trip up new contributors (see problem # 2 at the top). One counter-argument to this approach is the introduction of an additional step (compile and commit) to keep the RichFaces build current. However this is essentially the same as it is now, since one has to update the submodule and commit the submodule change to the RichFaces repo. This approach also has the advantage of being "The Simplest Thing That Could Possibly Work" [B], and would get us rolling with a workable solution right away. We could re-visit the problem down the road when the maven/node plugins have matured. Thoughts? [A] https://issues.jboss.org/browse/RF-13123 [B] http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html Posted by forums Original post: https://community.jboss.org/message/841394#841394

10 years, 6 months

4
4
0 / 0

[richfaces-dev] Forums & ML sync test 2

by richfaces-dev＠lists.jboss.org

Just testing Forums & ML synchronization. Test 2 This e-mail should end in https://lists.jboss.org/mailman/listinfo/richfaces-dev L. Posted by forums Original post: https://community.jboss.org/message/841354#841354

10 years, 6 months

5
8
0 / 0

[richfaces-dev] What are next steps for Photoalbum?

by Lukáš Fryč

Photoalbum was prototyped as a migration sample for RF4.3 and further improved in RF5: https://github.com/richfaces/richfaces/commits/master/examples/photoalbum (see the commit range from 5.0.0.Alpha1 to now). ---- We would like to use it as a sample app for RF 4.3 and thus some fixes are needed. The idea was to copy merge RF5 Photoalbum with RF 4.3 state. Note that Jiri Stefek also recently opened a pull request with patches for RF 4.3 state: https://github.com/richfaces4/dev-examples/pull/20 ---- Idea: We could copy a state of the demo from RF5 and apply it to RF4.3 (changing all r: components to a4j:). Another Idea: It would be great If Jiri could re-apply the changes from RF4.3 to RF5. Posted by forums Original post: https://community.jboss.org/message/841560#841560

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

richfaces-dev October 2013