Click
  1. Click
  2. CLK-328

click.xml should alow more than one pages-package

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5 M3
    • Component/s: None
    • Labels:
      None

      Description

      Hi,

      Frequently I have to write the same Page again and again in some projects, and do a lot of copy and paste. It will be very good if I could have some Pages in some *.jar and just uses it in the project. I just need to copy the *.htm pages to the webroot directory.... or.... the Page could autodeploy the *.htm files.

      For example for my customer, we always need pages to search employees in LDAP, search car´s etc... and CRUD operations... I would like to create all of this just once, and deploy a simple *.jar in the classpath.

      is it possible? thank you
      Ricardo

        Activity

        Hide
        Ricardo R. Lecheta added a comment -

        other good improvement is to add some namespace to the <pages...

        Show
        Ricardo R. Lecheta added a comment - other good improvement is to add some namespace to the <pages...
        Hide
        Ricardo R. Lecheta added a comment -

        other good improvement is to add some namespace to the <pages...

        example:

        <pages package="com.company.app.page" automapping="true" namespace="foo">

        so the *.htm files could be available in the /foo folder in the webroot

        Show
        Ricardo R. Lecheta added a comment - other good improvement is to add some namespace to the <pages... example: <pages package="com.company.app.page" automapping="true" namespace="foo"> so the *.htm files could be available in the /foo folder in the webroot
        Hide
        Malcolm Edgar added a comment -

        This feature would be a good candidate for the 1.5-M1 release, we should discuss this on the dev list.

        I think the important thing with this feature is to keep it very simple and limited scope.

        Show
        Malcolm Edgar added a comment - This feature would be a good candidate for the 1.5-M1 release, we should discuss this on the dev list. I think the important thing with this feature is to keep it very simple and limited scope.
        Hide
        Ahmed Mohombe added a comment -

        > This feature would be a good candidate for the 1.5-M1 release, we should discuss this on the dev list.
        >
        > I think the important thing with this feature is to keep it very simple and limited scope.
        We discussed this feature earlier, but the naming was different .
        Basically it consists of several independent issues:

        #1 Allow multiple <pages> elements in click.xml, thus allowing to
        automap multiple packages by the same automations available for the actual "single root" automapping
        functionality.

        #2 Allow to specify a "root" directory as the root of automapping
        <pages package="com.company.app.crm.page" root="/customers">
        (automapping="true" is default)
        thus allowing to separate parts of application and achieve a modularity.

        #2.1 Not specifying a "root" attribute means root="/" -> the actual behavior, so
        this keeps click.xml compatible with earlier versions.

        #3 The above #1 and #2 requests introduce the possibility of conflicts where
        subpackages from different <pages> nodes collide. Solve this by a simple
        "override" approach, i.e. take in consideration the the order of <pages> nodes:
        the later nodes, override the earlier ones.
        Example:
        Let's suppose the following two "modules"
        CRM
        1.1 com.company.crm.page.Home.class
        1.2 com.company.crm.page.admin.Dashboard.class
        1.3 com.company.crm.page.admin.Customers.class

        DOCS
        2.1 com.company.docs.page.DocList.class
        2.2 com.company.docs.page.Dashboard.class
        2.3 com.company.docs.page.DocumentEdit.class
        2.3 com.company.docs.page.Home.class

        Automapped as follows:
        <pages package="com.company.crm.page">
        <pages package="com.company.docs.page" root="/admin">

        In this mapping, 1.2 would collide with 2.2.
        Applying the override rule, 2.2 would win and would be really the final page used when
        calling /admin/dashboard.htm (or /admin/dashboard.jsp).

        #4 OnDeploy (autodeployment) should work the same way it's working for third party controls
        right now: using an ANT task to autodeploy an entire JAR containing not only the classes
        but the resources and *.htm (and *.jsp) pages too.
        The only difference from controls would be the existence of "root" attribute. If present
        e.g. root="/admin" than all deployed *.htm files are relative to that directory.

        When only implemented as a entire make this feature really easy to use and "click like", since
        only than takes away the most of the work from the user.

        Ahmed.

        -------------------------------------------------------------------------
        This SF.net email is sponsored by: Microsoft
        Defy all challenges. Microsoft(R) Visual Studio 2008.
        http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ahmed Mohombe added a comment - > This feature would be a good candidate for the 1.5-M1 release, we should discuss this on the dev list. > > I think the important thing with this feature is to keep it very simple and limited scope. We discussed this feature earlier, but the naming was different . Basically it consists of several independent issues: #1 Allow multiple <pages> elements in click.xml, thus allowing to automap multiple packages by the same automations available for the actual "single root" automapping functionality. #2 Allow to specify a "root" directory as the root of automapping <pages package="com.company.app.crm.page" root="/customers"> (automapping="true" is default) thus allowing to separate parts of application and achieve a modularity. #2.1 Not specifying a "root" attribute means root="/" -> the actual behavior, so this keeps click.xml compatible with earlier versions. #3 The above #1 and #2 requests introduce the possibility of conflicts where subpackages from different <pages> nodes collide. Solve this by a simple "override" approach, i.e. take in consideration the the order of <pages> nodes: the later nodes, override the earlier ones. Example: Let's suppose the following two "modules" CRM 1.1 com.company.crm.page.Home.class 1.2 com.company.crm.page.admin.Dashboard.class 1.3 com.company.crm.page.admin.Customers.class DOCS 2.1 com.company.docs.page.DocList.class 2.2 com.company.docs.page.Dashboard.class 2.3 com.company.docs.page.DocumentEdit.class 2.3 com.company.docs.page.Home.class Automapped as follows: <pages package="com.company.crm.page"> <pages package="com.company.docs.page" root="/admin"> In this mapping, 1.2 would collide with 2.2. Applying the override rule, 2.2 would win and would be really the final page used when calling /admin/dashboard.htm (or /admin/dashboard.jsp). #4 OnDeploy (autodeployment) should work the same way it's working for third party controls right now: using an ANT task to autodeploy an entire JAR containing not only the classes but the resources and *.htm (and *.jsp) pages too. The only difference from controls would be the existence of "root" attribute. If present e.g. root="/admin" than all deployed *.htm files are relative to that directory. When only implemented as a entire make this feature really easy to use and "click like", since only than takes away the most of the work from the user. Ahmed. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development
        Hide
        Malcolm Edgar added a comment -

        +1

        With #4 are you talking about adding the onDeploy() method to the Page class to support the deployment of page templates?

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - +1 With #4 are you talking about adding the onDeploy() method to the Page class to support the deployment of page templates? regards Malcolm Edgar
        Hide
        Ahmed Mohombe added a comment -

        > With #4 are you talking about adding the onDeploy() method to the Page class to support the deployment of page templates?
        Not necessarily (but it can be done like that too).
        The effect should be only similar.

        In this case however the there's no need to do this for each page individually,
        but for the entire jar.

        There's a big difference between a Page and a Control:

        • a control can have many many resources (e.g. EditArea or SyntaxHighlight from my sandbox) so an
          onDeploy per control makes sense,
        • a page has only a single *.htm (or *.jsp) file.
        • additionally, the entire JAR has a few global resources (images, and style) that need to
          be deployed too.

        This is why *.htm files(and additional resources) can be handled "in bulk" when processing <pages>
        node, by using a similar file like one generated for third party controls - everything automated
        and transparent to the user.

        Ahmed.

        -------------------------------------------------------------------------
        This SF.net email is sponsored by: Microsoft
        Defy all challenges. Microsoft(R) Visual Studio 2008.
        http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ahmed Mohombe added a comment - > With #4 are you talking about adding the onDeploy() method to the Page class to support the deployment of page templates? Not necessarily (but it can be done like that too). The effect should be only similar. In this case however the there's no need to do this for each page individually, but for the entire jar. There's a big difference between a Page and a Control: a control can have many many resources (e.g. EditArea or SyntaxHighlight from my sandbox) so an onDeploy per control makes sense, a page has only a single *.htm (or *.jsp) file. additionally, the entire JAR has a few global resources (images, and style) that need to be deployed too. This is why *.htm files(and additional resources) can be handled "in bulk" when processing <pages> node, by using a similar file like one generated for third party controls - everything automated and transparent to the user. Ahmed. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development
        Hide
        Malcolm Edgar added a comment -

        Ok Ahmed I think I understand your proposal.

        I am +1 for #1, #2, #3

        but -1 on #4, I think developers in this scenario can simple copy these page templates into their web project.

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Ok Ahmed I think I understand your proposal. I am +1 for #1, #2, #3 but -1 on #4, I think developers in this scenario can simple copy these page templates into their web project. regards Malcolm Edgar
        Hide
        Ahmed Mohombe added a comment -

        > Ok Ahmed I think I understand your proposal.
        >
        > I am +1 for #1, #2, #3
        >
        > but -1 on #4,
        .

        > I think developers in this scenario can simple copy these page templates into their web project.
        Yes, they can. They must not use the onDeploy function (like they must not use it
        now for controls - see TinyMCE example where onDeploy is not used), but in case they want
        to automate, IMHO there should be possible (the same way as for controls).

        The biggest advantage of #4 is that #3 would apply here automatically too, thus solving
        gracefully the conflicts (the developer will make no mistake).

        I already implemented this automation for 3rd party controls(given with too few documentation still
        ),
        and I think it's very very simple to have it for modules too.

        Anyway, this #4 feature is only for "modules" that are packed as jars and maybe come from 3rd
        parties like 3rd party controls too. This level of modularity is present as of today only in
        few Desktop applications.

        From an implementation point of view, it means only a single call when processing <pages> nodes.
        Of course, this could be even "false" by default, and if it's desired to look nice than it could be
        triggered only when an attribute is present:e.g. autodeploy=true

        Ahmed.

        -------------------------------------------------------------------------
        This SF.net email is sponsored by: Microsoft
        Defy all challenges. Microsoft(R) Visual Studio 2008.
        http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ahmed Mohombe added a comment - > Ok Ahmed I think I understand your proposal. > > I am +1 for #1, #2, #3 > > but -1 on #4, . > I think developers in this scenario can simple copy these page templates into their web project. Yes, they can. They must not use the onDeploy function (like they must not use it now for controls - see TinyMCE example where onDeploy is not used), but in case they want to automate, IMHO there should be possible (the same way as for controls). The biggest advantage of #4 is that #3 would apply here automatically too, thus solving gracefully the conflicts (the developer will make no mistake). I already implemented this automation for 3rd party controls(given with too few documentation still ), and I think it's very very simple to have it for modules too. Anyway, this #4 feature is only for "modules" that are packed as jars and maybe come from 3rd parties like 3rd party controls too. This level of modularity is present as of today only in few Desktop applications. From an implementation point of view, it means only a single call when processing <pages> nodes. Of course, this could be even "false" by default, and if it's desired to look nice than it could be triggered only when an attribute is present:e.g. autodeploy=true Ahmed. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development
        Hide
        Ricardo R. Lecheta added a comment -

        Hi Ahmed,

        do you have something of this already implemented to share with us?

        thank you
        Ricardo

        Show
        Ricardo R. Lecheta added a comment - Hi Ahmed, do you have something of this already implemented to share with us? thank you Ricardo
        Hide
        Ricardo Lecheta added a comment -

        Hi all,

        http://www.avoka.com/jira/browse/CLK-328

        anyone can help me with this?

        IMHO, this is one of the MOST important issues right now, and one that will
        improve the framework a lot, since it will be possible to reuse more code.

        Ahmed, I guess you have already implemented some prototype of this? Do you?

        thank you,
        Ricardo

        -------------------------------------------------------------------------
        This SF.net email is sponsored by: Microsoft
        Defy all challenges. Microsoft(R) Visual Studio 2008.
        http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ricardo Lecheta added a comment - Hi all, http://www.avoka.com/jira/browse/CLK-328 anyone can help me with this? IMHO, this is one of the MOST important issues right now, and one that will improve the framework a lot, since it will be possible to reuse more code. Ahmed, I guess you have already implemented some prototype of this? Do you? thank you, Ricardo ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development
        Hide
        Ahmed Mohombe added a comment -

        > http://www.avoka.com/jira/browse/CLK-328
        >
        > anyone can help me with this?
        >
        > IMHO, this is one of the MOST important issues right now, and one that will
        > improve the framework a lot, since it will be possible to reuse more code.

        > Ahmed, I guess you have already implemented some prototype of this? Do you?
        Nope .
        Better said I tried a long time ago but failed , since required some serious changing of how
        the automapping was working.

        I guess we need to refactor it as an utility to be reusable by tools too (e.g. for 100% correct
        navigation in IDEs or click related inspections, the same routine should be reused).

        I have however the #4 working. I'll check in here:
        /trunk/tools/standalone/dev-tasks/
        where's the place of all click tools (e.g. those from /trunk/click/lib/dev.jar too).

        Ahmed.

        -------------------------------------------------------------------------
        This SF.net email is sponsored by: Microsoft
        Defy all challenges. Microsoft(R) Visual Studio 2008.
        http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ahmed Mohombe added a comment - > http://www.avoka.com/jira/browse/CLK-328 > > anyone can help me with this? > > IMHO, this is one of the MOST important issues right now, and one that will > improve the framework a lot, since it will be possible to reuse more code. > Ahmed, I guess you have already implemented some prototype of this? Do you? Nope . Better said I tried a long time ago but failed , since required some serious changing of how the automapping was working. I guess we need to refactor it as an utility to be reusable by tools too (e.g. for 100% correct navigation in IDEs or click related inspections, the same routine should be reused). I have however the #4 working. I'll check in here: /trunk/tools/standalone/dev-tasks/ where's the place of all click tools (e.g. those from /trunk/click/lib/dev.jar too). Ahmed. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development
        Hide
        Malcolm Edgar added a comment -

        +1 on adding this feature, as detailed by Ahmed above on points #1, #2, #3.

        I am -1 on #4, as this falls into a different category of problem, i.e. modules or clickclick concepts. This is more complex, and there are a bunch of difficult issues
        to resolve, i.e. runtime deployment vs build time, JAR locking issues on Tomcat which we experienced with control.xml auto deployment, directory scanning, JAR unpacking...

        Show
        Malcolm Edgar added a comment - +1 on adding this feature, as detailed by Ahmed above on points #1, #2, #3. I am -1 on #4, as this falls into a different category of problem, i.e. modules or clickclick concepts. This is more complex, and there are a bunch of difficult issues to resolve, i.e. runtime deployment vs build time, JAR locking issues on Tomcat which we experienced with control.xml auto deployment, directory scanning, JAR unpacking...
        Hide
        Bob Schellink added a comment -

        I've been wondering about #2, the ability to configure a root directory for resources.

        I am not sure what other think #2 means but I take it that is the directory where resource should be copied to.

        For example say Joe provides me with a module called "shopping-cart" and I deploy it to the root "module1":

        /web/module1/js/shopping-cart-control.js
        /web/module1/images/sc.png
        /web/module1/border-template.htm
        /web/module1/shopping-cart.htm

        Of course Joe won't know that I deploy the module under "module1".

        The problem then comes with how Joe will specify resource paths.

        For example say he specified this page:

        public class BorderPage extends Page {
        public String getTemplate()

        { return "border-template.htm"; }

        }

        the above example won't work since border template path is: "/module1/border-template.htm".

        Another example would be the shopping-cart.htm template:

        <script src="/js/shopping-cart-control.js" ... ></script>

        again this won't work because the javascript path should be: '/module1/js/shopping-cart-control.js"

        So how do we solve this? Using relative paths? Relative paths won't work when sharing resources
        in different paths for example, say there are two templates:

        /web/module1/template.htm
        /web/module1/pages/template.htm

        and both templates makes use of super-control which looks like this:

        public class SuperControl extends AbstractControl {
        public String getHtmlImports()

        { return "../super-contro.js"; }

        }

        SuperControl might work for one template but not for the other, depending on the directory under which
        the template is saved under.

        Another option is to use the same solution we use for the context path. For example:
        $context/path-to-script.js

        For plugins the developer would have to do the following:

        public class SuperControl extneds AbstractControl {
        public String getHtmlImport()

        { return getContext().getPluginRoot("pluginName") + "/super-control.js"; }

        }

        and for templates:
        public class BorderPage extends Page {
        public String getTemplate()

        { return getContext().getPluginRoot("pluginNane") + "/border-template.htm"; }

        }

        and inside templates:
        <script src="$context / $pluginRoot("pluginName") / shopping-cart-control.js

        A third option would be to solve this by not having the problem in the first place. Meaning
        let the module developer define (hardcode) the "root" path and the user of that module cannot change it.

        Show
        Bob Schellink added a comment - I've been wondering about #2, the ability to configure a root directory for resources. I am not sure what other think #2 means but I take it that is the directory where resource should be copied to. For example say Joe provides me with a module called "shopping-cart" and I deploy it to the root "module1": /web/module1/js/shopping-cart-control.js /web/module1/images/sc.png /web/module1/border-template.htm /web/module1/shopping-cart.htm Of course Joe won't know that I deploy the module under "module1". The problem then comes with how Joe will specify resource paths. For example say he specified this page: public class BorderPage extends Page { public String getTemplate() { return "border-template.htm"; } } the above example won't work since border template path is: "/module1/border-template.htm". Another example would be the shopping-cart.htm template: <script src="/js/shopping-cart-control.js" ... ></script> again this won't work because the javascript path should be: '/module1/js/shopping-cart-control.js" So how do we solve this? Using relative paths? Relative paths won't work when sharing resources in different paths for example, say there are two templates: /web/module1/template.htm /web/module1/pages/template.htm and both templates makes use of super-control which looks like this: public class SuperControl extends AbstractControl { public String getHtmlImports() { return "../super-contro.js"; } } SuperControl might work for one template but not for the other, depending on the directory under which the template is saved under. Another option is to use the same solution we use for the context path. For example: $context/path-to-script.js For plugins the developer would have to do the following: public class SuperControl extneds AbstractControl { public String getHtmlImport() { return getContext().getPluginRoot("pluginName") + "/super-control.js"; } } and for templates: public class BorderPage extends Page { public String getTemplate() { return getContext().getPluginRoot("pluginNane") + "/border-template.htm"; } } and inside templates: <script src="$context / $pluginRoot("pluginName") / shopping-cart-control.js A third option would be to solve this by not having the problem in the first place. Meaning let the module developer define (hardcode) the "root" path and the user of that module cannot change it.
        Hide
        Malcolm Edgar added a comment -

        Have developed a simple implementation of supporting multiple pages elements in click.xml. For example:

        <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <click-app charset="UTF-8">
        <pages package="net.sf.click.examples.page"/>
        <pages package="com.mycorp.page"/>
        </click-app>

        XmlConfigService will process the multiple pages elements and load the pages. The current Click design works quite well, if a page template has already been mapped to a Page class it wont be remapped to a subsequent match. This design is for ensuring manually mapped pages are not overridden by automapped pages.

        However this also works well for this use case as well. Whichever <pages> package is first in the click.xml takes priority. This feels right to me as it is at the top of the list.

        This implementation does not include a pages root attribute, which I think should be handled in the Click modules.

        Show
        Malcolm Edgar added a comment - Have developed a simple implementation of supporting multiple pages elements in click.xml. For example: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <click-app charset="UTF-8"> <pages package="net.sf.click.examples.page"/> <pages package="com.mycorp.page"/> </click-app> XmlConfigService will process the multiple pages elements and load the pages. The current Click design works quite well, if a page template has already been mapped to a Page class it wont be remapped to a subsequent match. This design is for ensuring manually mapped pages are not overridden by automapped pages. However this also works well for this use case as well. Whichever <pages> package is first in the click.xml takes priority. This feels right to me as it is at the top of the list. This implementation does not include a pages root attribute, which I think should be handled in the Click modules.
        Hide
        Malcolm Edgar added a comment -

        Simple pages support implementation

        Show
        Malcolm Edgar added a comment - Simple pages support implementation

          People

          • Assignee:
            Malcolm Edgar
            Reporter:
            Ricardo R. Lecheta
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development