click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel" <>
Subject Issues or no issue...
Date Mon, 14 Jun 2010 16:33:00 GMT
Hi Guys,

While I was working on click-annotation project (which I have sent email
earlier on both user and dev group). I figured out couple of things. These
could be issues that need to be taken care off, or may be they are not
issues at all. I was not sure that's why I did not create any jira issue. If
Click expert guys verifies and agrees that some of them should be jira
issue, then I can raise the issue on jira. Issues are -

1) Private methods on XmlConfigService. While I was trying to integrate the
annotation processing stuffs, I figured out that the methods on
XmlConfigService is private/package local scope. Which strictly prohibits
the scope of extending the class to add more custom behavior. So, I had made
a true copy and then modify the class (made methods protected and splitted
common behavior). It will be really painful to update the true copy for
upcoming Click releases.

Then on issue CLK-343, I found this "One of the premises with the current
design was to hide the complexity of this stuff from end user. Which is why
the classes are not public, and they don't show up in Javadoc". Isn't that
we should make the API's as a jar and give javadoc for them, and make the
implementations on a separate jar (and the impl depending on api). That way,
we don't have to give the javadoc for impl, but the code is still there
anyone who is interested can look into it, if they want.

2) The same way DeployUtils class is package local, and I made a true copy.

3) The org.apache.Control interface was made to be both "a generic control"
and "a deploy aware control". Which I felt more of mixing of concern.
Shouldn't these be two separate interfaces. Like -

public interface DeployAwareControl{
     public void onDeploy(ServletContext context);

And for backward compatibility we can make Control interface extending

4) The "isTemplate" method is having a bug. In the method we are not
checking if the file is really a file or folder, Because on my Linux
(Ubuntu) I was able to create a folder with .htm  or .jsp extension. I know
this might not happen so often, but still I think it might create problem.

5) The entire code on XmlConfigService is not Java 1.5 compatible. Some of
it uses generics, and some of it does not.

6) When the application is loading, we load all page classes, and their
bindable page fields. Could be a memory issue when benchmarking Click
against other frameworks. We can load bindable page fields on demand, and
cache them. That way we will not end up loading all page fields even if its
not needed. For an application with 100 pages this could be a performance
issue. As an example: say on there are lots of pages
which is not browsed by user (example license content page, how to release,
and pages like that), those pages will still be loaded. I know an
application running for long time might be loading all pages eventually. But
still, we can load them on demand, and we can cache loaded classes. And we
can also keep the house keeping thread to eventually clear up rarely loaded

7) On "getBindablePageFields" method of XmlConfigService, this piece of code

Field[] publicFields = pageClass.getFields();
    for (Field field : publicFields) {
        fieldMap.put(field.getName(), field);

Though @Bindable fields are still processed, but here we again we are
processing all public fields (even though they have @Bindable and already
processed). Also there are some repetition of code (on if-else) block.
Possible to improve. Will help to get a better picture when benchmarking.

My English is not much good, and I did not have time to review the mail
before sending. So for any mistake, I apology. And if you do not understand
something, let me know, I will explain more about that.



View raw message