click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel" <development....@gmail.com>
Subject Re: [jira] Issue Comment Edited: (CLK-661) Add Java based configuration
Date Tue, 22 Jun 2010 13:21:25 GMT
Hi Finn and Bob,

The way I see it is, these services (xmlconfigservice,simpleconfigservice,
annotationconfigservice(which is on my doubleclick project)), requires a
massive refactoring. Each of these services should be event driven. I mean,
if these are the standard sequence(at least until now) -

1. loadLogService
2. loadMode
3. loadDeployFiles (must precede loadResourceService as the deployed
resources could be loaded by ResourceService if configured)
4. loadPages
5. order shouldn't matter

Then there should be one implementation which is generating event for all
config services. That way we can maintain the loading sequence. That way,
first it will generated "loadmode" event to the xmlconfigservice to load
mode, then annotationconfigservice to load mode......, then it will generate
"load deploy files", "load pages".... and so on.

The boostraping should not be sequential like as it is now on xmlconfig
service. which takes away the scope of extending/adding more config services
without touching existing one. right now, if we want to put in another
config service (say its simple config service, or annotation config service)
we have to touch the xmlconfigservice. because xmlconfigservice is putting
it all together inside it, and made methods package local or private.

And I absolutely agree with bob, that we should refactor the xmlconfig
service so that it does not takes xmlElm, but takes standard java element.

Please give input about the evendrive approach i mentioned above. if you
guys agree then i will really like to work with this task. right now i am
sick, so i could not finish one or more tasks that I said i will work no.
but hope to return soon.

Regards,

Jahid



On Tue, Jun 22, 2010 at 2:06 PM, Bob Schellink (JIRA) <jira@apache.org>wrote:

>
>    [
> https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881179#action_12881179]
>
> Bob Schellink edited comment on CLK-661 at 6/22/10 8:05 AM:
> ------------------------------------------------------------
>
> Hi Finn,
>
> This is a good start. My idea was to have a standalone Java based
> configuration that can be used in place of the click.xml file. While
> click.xml is quite simple and easy to read it becomes cumbersome when
> configuring multiple services or having dynamic behavior based on the
> production vs development modes.
>
> I shouldn't have called it DefaultConfigService since XmlConfigService will
> still be the default. Perhaps SimpleConfigService or even
> AbstractConfigService is a more apt name. Guess it will depend on how this
> service ends up being implemented.
>
> Ideally SimpleConfigService should be usable on its own with a minimal
> amount of configuration. I can imagine the following:
>
>  public class MyCorpConfigService extends SimpleConfigService {
>
>    @Override
>    protected List<String> loadPagePackages() {
>      return Collections.singletonList("com.mycorp");
>    }
>  }
>
> This could be enough to get a basic application up and running using the
> automapping feature to load pages from the given package.
>
> The order in which some services are loaded is quite sensitive so I agree
> with Jahid comments[1] that it shouldn't be left to the subclasses as they
> would likely get it wrong. If necessary we could group together related
> services. From memory I think the following order must be maintained:
>
> 1. loadLogService
> 2. loadMode
> 3. loadDeployFiles (must precede loadResourceService as the deployed
> resources could be loaded by ResourceService if configured)
> 4. loadPages
> 5. order shouldn't matter
>
>
> So assuming we agree that SimpleConfigService should be usable on its own,
> the question comes how we expect users to customize it. On the face of it it
> seems like a good fit for Template Pattern where the SimpleConfigService
> contains the driver code and expose some loadXXX methods which users or
> subclasses can override to return alternate implementations.
> XmlConfigService already follows this pattern except the loadXXX methods are
> private and accepts a rootElm as argument. This does highlight an immediate
> issue on how XmlConfigService would override the loadXXX methods. Since
> SimpleConfigService won't pass any arguments to its methods, the Xml rootElm
> would need to be stored as a variable on XmlConfigService for these methods
> to access.
>
> Anyway I've rambled enough, let me know what you think.
>
> [1]: http://markmail.org/message/4iyaqlqyroyw7rjs
>
>
>      was (Author: sabob):
>    Hi Finn,
>
> This is a good start. My idea was to have a standalone Java based
> configuration that can be used in place of the click.xml file. While
> click.xml is quite simple and easy to read it becomes cumbersome when
> configuring multiple services or having dynamic behavior based on the
> production vs development modes.
>
> I shouldn't have called it DefaultConfigService since XmlConfigService will
> still be the default. Perhaps SimpleConfigService or even
> AbstractConfigService is a more apt name. Guess it will depend on how this
> service ends up being implemented.
>
> Ideally SimpleConfigService should be usable on its own with a minimal
> amount of configuration. I can imagine the following:
>
>  public class MyCorpConfigService extends SimpleConfigService {
>
>    public List<String> loadPagePackages() {
>      return Collections.singletonList("com.mycorp");
>    }
>  }
>
> This could be enough to get a basic application up and running using the
> automapping feature to load pages from the given package.
>
> The order in which some services are loaded is quite sensitive so I agree
> with Jahid comments[1] that it shouldn't be left to the subclasses as they
> would likely get it wrong. If necessary we could group together related
> services. From memory I think the following order must be maintained:
>
> 1. loadLogService
> 2. loadMode
> 3. loadDeployFiles (must precede loadResourceService as the deployed
> resources could be loaded by ResourceService if configured)
> 4. loadPages
> 5. order shouldn't matter
>
>
> So assuming we agree that SimpleConfigService should be usable on its own,
> the question comes how we expect users to customize it. On the face of it it
> seems like a good fit for Template Pattern where the SimpleConfigService
> contains the driver code and expose some loadXXX methods which users or
> subclasses can override to return alternate implementations.
> XmlConfigService already follows this pattern except the loadXXX methods are
> private and accepts a rootElm as argument. This does highlight an immediate
> issue on how XmlConfigService would override the loadXXX methods. Since
> SimpleConfigService won't pass any arguments to its methods, the Xml rootElm
> would need to be stored as a variable on XmlConfigService for these methods
> to access.
>
> Anyway I've rambled enough, let me know what you think.
>
> [1]: http://markmail.org/message/4iyaqlqyroyw7rjs
>
>
> > Add Java based configuration
> > ----------------------------
> >
> >                 Key: CLK-661
> >                 URL: https://issues.apache.org/jira/browse/CLK-661
> >             Project: Click
> >          Issue Type: Improvement
> >            Reporter: Bob Schellink
> >            Assignee: Finn Bock
> >             Fix For: 2.3.0-M1
> >
> >         Attachments: defaultconfigservice.patch
> >
> >
> > click.xml has grown over the years especially since we introduced the
> service based architecture. Some of the problems with xml based
> configurations is:
> > - no compile time checking
> > - no JavaDoc help in IDE
> > I propose we add a new DefaultConfigService class that is Java based
> which XmlConfigService extends from.
> > Its advantages is the polar opposite of xml disadvantage:
> > - compile time checking
> > - JavaDoc help in IDE
> > - More powerful configuration options, e.g. its possible to configure
> FileUpload in ways not exposed by xml config. Also possible to create more
> powerful algorithms e.g. which templates to include/exclude.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Mime
View raw message