tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TAP5-2192) Add support for distributed documentation
Date Tue, 08 Jul 2014 00:11:34 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054271#comment-14054271
] 

Lance edited comment on TAP5-2192 at 7/8/14 12:09 AM:
------------------------------------------------------

How's this for a compromise... my main problem is requiring the configuration inside tapestry.
I don't necessarily mind that it's modelled inside tapestry.

1. Remove getComponentLibraryInfo() from LibraryMapping
2. Add ComponentLibraryInfoSource
{code}
public interface ComponentLibraryInfoSource {
   ComponentLibraryInfo getComponentLibraryInfo(String libraryName);
}
{code}
3. Change ComponentLibraryInfo to use Resource instead of String URL's. eg
{code}
public interface ComponentLibraryInfo {
   Resource getHomePageRoot();
   Resource getSourceRoot();
   Resource getJavadocRoot();
   // etc
}
{code}

This way, ComponentLibraryInfoSource could be contributed to and overridden. Perhaps driven
by an XML file generated at build time etc. Or better yet, library authors could add the maven
version / artifact to the jar manifest and the service could look it up. 

Using Resource also allows javadoc and sources to be sourced from classpath or a URL etc.

This feels much more like 'the tapestry way' of doing things.


was (Author: uklance):
How's this for a compromise... my main problem is requiring the configuration inside tapestry.
I don't necessarily mind that it's modelled inside tapestry.

1. Remove getComponentLibraryInfo() from LibraryMapping
2. Add ComponentLibraryInfoSource
{code}
public interface ComponentLibraryInfoSource {
   ComponentLibraryInfo getComponentLibraryInfo(String libraryName);
}
{code}
3. Change ComponentLibraryInfo to use Resource instead of String URL's. eg
{code}
public interface ComponentLibraryInfo {
   Resource getHomePageRoot();
   Resource getSourceRoot();
   Resource getJavadocRoot();
   // etc
}
{code}

This way, ComponentLibraryInfoSource could be contributed to and overridden. Perhaps driven
by an XML file generated at build time etc. Using Resource also allows javadoc to be sourced
from classpath or a URL etc.

This feels much more like 'the tapestry way' of doing things.

> Add support for distributed documentation
> -----------------------------------------
>
>                 Key: TAP5-2192
>                 URL: https://issues.apache.org/jira/browse/TAP5-2192
>             Project: Tapestry 5
>          Issue Type: Improvement
>    Affects Versions: 5.4
>            Reporter: Barry Books
>            Assignee: Thiago H. de Paula Figueiredo
>              Labels: documentation, month-of-tapestry
>
> Please add support for a distributed documentation system. The basic requirements are:
> 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver supports pages)
> 2. Access to a Map of all Configurations. The map would have the configuration class
as the Key and contain an object such a list or map that contains the configuration.
> 3. Access to a list of configured services.
> From this it should be possible to build documentation of a running system. 
> Thanks
> Barry



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message