Design Discussions

[cagatay.civici]

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.

[Oleg]

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.

Code: Select all

Collection<List<ClientBehavior>> clientBehaviors = TagUtils.getClientBehaviors(ctx, event, (ClientBehaviorHolder) parent);

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.

[tandraschko]

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?"

[Oleg]

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?

[tandraschko]

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

[Oleg]

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?

[cagatay.civici]

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!

[Oleg]

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

[seanpuallynch]

Yes "p:resetInput is a really great component i am using it....

[Oleg]

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:

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));
}

where

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();
}

I re-think this stuff now. Why do we need escapeText() at all? If escaping, then only for printable characters, like

Code: Select all

div[title="I'm with single quote, and comma"]

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

Code: Select all

.firstclass, .secondclass

Hence, we can't use escaping or methods as in Tobago's jQueryUtils http://grepcode.com/file/repo1.maven.or ... Utils.java Right?

Wdyt?