Sorry, I couldn't catch with latest design discussion, I think I'll have some time to reply this weekend.
By the way, how about promoting pe:resetInput to PrimeFaces? It is extremely handy.
Design Discussions
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
Hi Cagatay,
That's good if you will have some time to reply this weekend. Because I thought you ignore design discussions.
I have nothing against promotion pe:resetInput to PrimeFaces if other team members agree. The problem is only if you will modify the logic in pe:resetInput (well tested by the way) and it will not work for all use cases and you don't have time to fix this... Or, for instance, you will drop the support for f:ajax or something else. You know what I mean. I mean in PF Extensions we have a fully control for our components. Furthermore, ResetInput uses some base classes / utility methods from PrimeFaces Extensions. E.g.
I don't know...
Edit: So, if it's possible to accept this component 1 to 1 without much changes, then it's ok. It's working well, simple to use, can be attached to ALL ActionSource and ClientBehaviorHolder (Ajax) components - features we need when we will remove this comp. from Extensions.
That's good if you will have some time to reply this weekend. Because I thought you ignore design discussions.
I have nothing against promotion pe:resetInput to PrimeFaces if other team members agree. The problem is only if you will modify the logic in pe:resetInput (well tested by the way) and it will not work for all use cases and you don't have time to fix this... Or, for instance, you will drop the support for f:ajax or something else. You know what I mean. I mean in PF Extensions we have a fully control for our components. Furthermore, ResetInput uses some base classes / utility methods from PrimeFaces Extensions. E.g.
Code: Select all
Collection<List<ClientBehavior>> clientBehaviors = TagUtils.getClientBehaviors(ctx, event, (ClientBehaviorHolder) parent);
Edit: So, if it's possible to accept this component 1 to 1 without much changes, then it's ok. It's working well, simple to use, can be attached to ALL ActionSource and ClientBehaviorHolder (Ajax) components - features we need when we will remove this comp. from Extensions.
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- PrimeFaces Core Developer
- Posts: 3979
- Joined: 03 Dec 2010, 14:11
- Location: Bavaria, DE
- Contact:
IMO it would be nice to see this compoent in PrimeFaces Core but it's also ok that we maintain it
Cagatay, is there any possiblity that we can provide patches for issues which hits us?
For example, if a bug occurs in PrimeFaces Extensions, i can fix it and commit it on the same day.
If the component was moved to Core, it could take weeks/months till you have time to fix it.
It would be cool if we could somehow ping you with: "Hey Cagatay, we applied a patch for issue #xxx and works fine in our app. Could you please review it and commit it?"
Cagatay, is there any possiblity that we can provide patches for issues which hits us?
For example, if a bug occurs in PrimeFaces Extensions, i can fix it and commit it on the same day.
If the component was moved to Core, it could take weeks/months till you have time to fix it.
It would be cool if we could somehow ping you with: "Hey Cagatay, we applied a patch for issue #xxx and works fine in our app. Could you please review it and commit it?"
Thomas Andraschko
PrimeFaces | PrimeFaces Extensions
Apache Member | OpenWebBeans, DeltaSpike, MyFaces, BVal, TomEE
Sponsor me: https://github.com/sponsors/tandraschko
Blog: http://tandraschko.blogspot.de/
Twitter: https://twitter.com/TAndraschko
PrimeFaces | PrimeFaces Extensions
Apache Member | OpenWebBeans, DeltaSpike, MyFaces, BVal, TomEE
Sponsor me: https://github.com/sponsors/tandraschko
Blog: http://tandraschko.blogspot.de/
Twitter: https://twitter.com/TAndraschko
Cagatay, what we would like to give off:
1) AjaxStatus, pe:ajaxStatus (support for standard f:ajax for legacy / mix applications).
2) Javascript, pe:javascript (leightweigt p:ajax without much JS code and semantic better than using of p:ajax for only client-side calls).
3) Paginator, pe:paginator (we discussed it here, it still useful to have although some people think "it's just another configuration").
4) ResetInput, pe:resetInput (very handy component, we are agree to move it if you will keep the code as it is).
That are 4 candidates at the moment. Of course, you can also take all utils if you want - we have p:importConstants and soon pe:switch / pe:case (analog to JSTL but components).
What do you think?
1) AjaxStatus, pe:ajaxStatus (support for standard f:ajax for legacy / mix applications).
2) Javascript, pe:javascript (leightweigt p:ajax without much JS code and semantic better than using of p:ajax for only client-side calls).
3) Paginator, pe:paginator (we discussed it here, it still useful to have although some people think "it's just another configuration").
4) ResetInput, pe:resetInput (very handy component, we are agree to move it if you will keep the code as it is).
That are 4 candidates at the moment. Of course, you can also take all utils if you want - we have p:importConstants and soon pe:switch / pe:case (analog to JSTL but components).
What do you think?
Last edited by Oleg on 22 Jun 2012, 16:39, edited 1 time in total.
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- PrimeFaces Core Developer
- Posts: 3979
- Joined: 03 Dec 2010, 14:11
- Location: Bavaria, DE
- Contact:
Cagatay, we already moved some features and in the future we will move other components too. What about a "thanks" or "contributor" page for us?
I know that many people will say "p:resetInput is a really great component. Thanks Cagatay and PrimeFaces team!!!" and we developed it
I know that many people will say "p:resetInput is a really great component. Thanks Cagatay and PrimeFaces team!!!" and we developed it
Thomas Andraschko
PrimeFaces | PrimeFaces Extensions
Apache Member | OpenWebBeans, DeltaSpike, MyFaces, BVal, TomEE
Sponsor me: https://github.com/sponsors/tandraschko
Blog: http://tandraschko.blogspot.de/
Twitter: https://twitter.com/TAndraschko
PrimeFaces | PrimeFaces Extensions
Apache Member | OpenWebBeans, DeltaSpike, MyFaces, BVal, TomEE
Sponsor me: https://github.com/sponsors/tandraschko
Blog: http://tandraschko.blogspot.de/
Twitter: https://twitter.com/TAndraschko
After re-thinking promotion of pe:resetInput, I still not understand why we need to do this. What is problem to use PF Extensions? It's only one dependency. It would be better if we could maintain our components.
As long as we don't have committer roles, we will always have this kind of problem. Another "side-effect" are duplicate components. It's not a big problem, but having double components is kinda not good. Unfortunately, there isn't other way. For instance, I would like to remove pe:blockUI, because PrimeFaces has it too. But I can't do this. p:blockUI doesn't support AJAX events selective. You can not say "block something for datatable sorting, but don't block for filtering". The second problem, p:blockUI doesn't care about blocking the same target by multiply AJAX calls. Imagine, user clicks fast on tree nodes, block the same target, first response unblocks the target, but other requests are still running, so that unblocking is not valid. pe:blockUI handles this collision properly. This is why I said I can't remove pe:blockUI (we lost features then) and I would not promote pe:resetInput (we lost control on this comp. then). And finally, as Thomas said, we spent some time to design and develop pe:resetInput and are proud of it.
I think we belong to the PrimeFaces infrastructure, we don't steal components as ICEFaces, we don't offer commercial support and don't implement missing in PF features for less money. This would be unfair to PrimeFaces, in my opinion. We developed some components just for fun, for PrimeFaces community. So, if users want, they can use Extensions, Prime Technology can use it for internal projects too. If you miss something, you can open issues / ask for new features, we will try to do our best and keep our components intact, no worries. Why to move new components to the core project now? We would appreciate to enhance existing components, like AjaxStatus, BlockUI, Layout, RemoteCommand and remove duplicate components. But please, let us maintain unique components by Extensions. Ok?
As long as we don't have committer roles, we will always have this kind of problem. Another "side-effect" are duplicate components. It's not a big problem, but having double components is kinda not good. Unfortunately, there isn't other way. For instance, I would like to remove pe:blockUI, because PrimeFaces has it too. But I can't do this. p:blockUI doesn't support AJAX events selective. You can not say "block something for datatable sorting, but don't block for filtering". The second problem, p:blockUI doesn't care about blocking the same target by multiply AJAX calls. Imagine, user clicks fast on tree nodes, block the same target, first response unblocks the target, but other requests are still running, so that unblocking is not valid. pe:blockUI handles this collision properly. This is why I said I can't remove pe:blockUI (we lost features then) and I would not promote pe:resetInput (we lost control on this comp. then). And finally, as Thomas said, we spent some time to design and develop pe:resetInput and are proud of it.
I think we belong to the PrimeFaces infrastructure, we don't steal components as ICEFaces, we don't offer commercial support and don't implement missing in PF features for less money. This would be unfair to PrimeFaces, in my opinion. We developed some components just for fun, for PrimeFaces community. So, if users want, they can use Extensions, Prime Technology can use it for internal projects too. If you miss something, you can open issues / ask for new features, we will try to do our best and keep our components intact, no worries. Why to move new components to the core project now? We would appreciate to enhance existing components, like AjaxStatus, BlockUI, Layout, RemoteCommand and remove duplicate components. But please, let us maintain unique components by Extensions. Ok?
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
Ok there is a misunderstanding, let me clarify
What I actually mean by promoting is moving the "idea" of an extensions to PrimeFaces and fork it. I don't mean promoting the actual code of extensions and delete it. One example is pe:requiredLabel, there is p:outputLabel inspired by it. Extensions should not just mean new components but also extended features to existing components and forks. I do my best to promote extensions project (dedicated forum here, link on primefaces.org) and it actually pays off. I see many projects using extensions.
So to summarize, I should be more clear about using the term "promote" Just like what we did for p:outputLabel - pe:requiredLabel case, there should be p:resetInput and pe:resetInput. There should be a choice, for example some people prefer pe:layout or pe:blockUI instead of p counterparts.
Hope you get my point, extensions is an important project for the PrimeFaces Community!
What I actually mean by promoting is moving the "idea" of an extensions to PrimeFaces and fork it. I don't mean promoting the actual code of extensions and delete it. One example is pe:requiredLabel, there is p:outputLabel inspired by it. Extensions should not just mean new components but also extended features to existing components and forks. I do my best to promote extensions project (dedicated forum here, link on primefaces.org) and it actually pays off. I see many projects using extensions.
So to summarize, I should be more clear about using the term "promote" Just like what we did for p:outputLabel - pe:requiredLabel case, there should be p:resetInput and pe:resetInput. There should be a choice, for example some people prefer pe:layout or pe:blockUI instead of p counterparts.
Hope you get my point, extensions is an important project for the PrimeFaces Community!
All right, Cagatay. You are free of course to create p:resetInput. I don't see here any problems. You are right, there isn't problem to have counterparts, as long they have some different parts.
P.S. Don't forget tooltip for p:progressBar please
P.S. Don't forget tooltip for p:progressBar please
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Posts: 1
- Joined: 25 Jul 2012, 09:15
- Contact:
Yes "p:resetInput is a really great component i am using it....
Hi Cagatay, Thomas.
One thing makes me headache. Escaping of jQuery selectors in Java. Some PF components, like e.g. Watemark, have "for" and "forElement" attributes. The same is valid for a lot of PF Extensions components. We have there "for" and "forSelector". What do you think, should we escape selectors in Java or should user escape them? PrimeFaces doesn't care about this and doesn't escape them. PF Extensions escape, but a little bit strange. What we do is:
where
I re-think this stuff now. Why do we need escapeText() at all? If escaping, then only for printable characters, like
but we can not escape the entire selector because these characters are reserved for selectrors self http://www.xinotes.org/notes/note/958/. E.g. comma
Hence, we can't use escaping or methods as in Tobago's jQueryUtils http://grepcode.com/file/repo1.maven.or ... Utils.java Right?
Wdyt?
One thing makes me headache. Escaping of jQuery selectors in Java. Some PF components, like e.g. Watemark, have "for" and "forElement" attributes. The same is valid for a lot of PF Extensions components. We have there "for" and "forSelector". What do you think, should we escape selectors in Java or should user escape them? PrimeFaces doesn't care about this and doesn't escape them. PF Extensions escape, but a little bit strange. What we do is:
Code: Select all
private static String findTarget(FacesContext context, Attachable attachable, UIComponent component) {
final String forValue = attachable.getFor();
if (forValue != null) {
final UIComponent forComponent = component.findComponent(forValue);
if (forComponent == null) {
throw new FacesException("Cannot find component '" + forValue + "'.");
}
return escapeJQueryId(forComponent.getClientId(context));
}
if (attachable instanceof EnhancedAttachable) {
final EnhancedAttachable enhancedAttachable = (EnhancedAttachable) attachable;
final String forSelector = enhancedAttachable.getForSelector();
if (forSelector != null) {
if (forSelector.startsWith("#")) {
return escapeComponentId(forSelector);
} else {
return escapeText(forSelector);
}
}
}
return escapeJQueryId(component.getParent().getClientId(context));
}
Code: Select all
public static String escapeJQueryId(String id) {
return "#" + id.replaceAll(":", "\\\\\\\\:");
}
public static String escapeComponentId(final String id) {
return id.replaceAll(":", "\\\\\\\\:");
}
/**
* Duplicate code from json-simple project under apache license
* http://code.google.com/p/json-simple/source/browse/trunk/src/org/json/simple/JSONValue.java
*
* @param text original text as string
* @return String escaped text as string to be used as JSON value
*/
public static String escapeText(final String text) {
if (text == null) {
return null;
}
StringBuilder sb = new StringBuilder();
for (int i = 0; i < text.length(); i++) {
char ch = text.charAt(i);
switch (ch) {
case '"':
sb.append("\\\"");
break;
case '\\':
sb.append("\\\\");
break;
case '\b':
sb.append("\\b");
break;
case '\f':
sb.append("\\f");
break;
case '\n':
sb.append("\\n");
break;
case '\r':
sb.append("\\r");
break;
case '\t':
sb.append("\\t");
break;
case '/':
sb.append("\\/");
break;
default:
//Reference: http://www.unicode.org/versions/Unicode5.1.0/
if ((ch >= '\u0000' && ch <= '\u001F') || (ch >= '\u007F' && ch <= '\u009F')
|| (ch >= '\u2000' && ch <= '\u20FF')) {
String ss = Integer.toHexString(ch);
sb.append("\\u");
for (int k = 0; k < 4 - ss.length(); k++) {
sb.append('0');
}
sb.append(ss.toUpperCase());
} else {
sb.append(ch);
}
}
}
return sb.toString();
}
Code: Select all
div[title="I'm with single quote, and comma"]
Code: Select all
.firstclass, .secondclass
Wdyt?
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Information
-
Who is online
Users browsing this forum: No registered users and 19 guests