avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
Date Thu, 29 Aug 2002 15:30:34 GMT

Peter Donald wrote:
> On Thu, 29 Aug 2002 17:23, Nicola Ken Barozzi wrote:
> 
>>Peter Donald wrote:
>>
>>>On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
>>>
>>>>Ok, I understand the need, but then, why under the attributes?
>>>>Why not a <description> taga ala Ant, it doesn't seem like a generic
>>>>attribut to me...
>>>
>>>The problem is when you want to do i18n of the description. Currently it
>>>is done via
>>>
>>><!-- use the following if you dont care about i18n -->
>>><attribute name="doc:description" value="Some description" />
>>>
>>><!--  use the following if you do care about i18n. -->
>>><attribute name="doc:description-key" value="my.key" />
>>>
>>><!--
>>>  Note that you would have to include a resources
>>>  file side-by-side the info file with the name
>>>  MyClassNameInfo.*. However you could overide
>>>  the location of the Info file via
>>>-->
>>><attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
>>>
>>>I think I would prefer a description element, but how would you deal with
>>>the above?
>>
>>There are various options, here are the most relevant:
>>
>>XML language identification
>>-----------------------------
>>http://www.w3.org/TR/REC-xml#sec-lang-tag
>>
>><description>
>>   <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
>>   <p xml:lang="en-GB">What colour is it?</p>
>>   <p xml:lang="en-US">What color is it?</p>
>>   <sp who="Faust" desc='leise' xml:lang="de">
>>     <l>Habe nun, ach! Philosophie,</l>
>>     <l>Juristerei, und Medizin</l>
>>     <l>und leider auch Theologie</l>
>>     <l>durchaus studiert mit heißem Bemüh'n.</l>
>>   </sp>
>></description>
>>
>>Comment: standard, but not flexible enough.
>>
>>Cocoon i18n tags:
>>------------------
>>http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
>>
>><description>
>>   <para title="first" name="article"  i18n:attr="title name">
>>     <i18n:text>This text will be translated.</i18n:text>
>>   </para>
>>   <i18n:text i18n:key="key_text">Default value</i18n:text>
>>   <i18n:translate>
>>	<i18n:text>Some {0} was inserted {1}.</i18n:text>
>>	<i18n:param>text</i18n:param>
>>	<i18n:param>here</i18n:param>
>>   </i18n:translate>
>></description>
>>
>>Comment:
>>important features are:
>>- Attribute translation
>>- Param substitution
>>It's more flexible and already has a Transformer to do the work, also
>>from an i18n file
>>Since Morphos can easily be made to use Cocoon Components, it can easily
>>be used as a MorpherAntTask to do the transformations.
> 
> 
> Both solutions all seem a bit complex. Descriptions are essentially blobs of 
> text and thus don't need substitution or anything like that. All they need is 
> to say blob A is in language X while blob B is in language Y.

Hmmm... I'd just keep the description in one language with descriptions 
via a key in a bundle...

>>We could just use a standard name for the bundle, keep english stuff in
>>the descriptor and a key for external translations.
> 
> WHich is precisely the reasoning that lead me to use attributes ;)

What about this then.
I changed the example componentinfo dtd to make it more consistent, 
extensible and near to literate programming, which has struck a cord in 
me lately.

We have

  -[1]component-info

    -[1]component-entry
      -[1..n]attribute

    -[1]context-entry
      -[1..n]attribute

    -[1..n]service-entry
      -[1..n]attribute

    -[1..n]dependency-entry
      -[1..n]attribute

Each entry has these:

   - entry - id
           - version
           - optional y/n

Each attribute has these:

   - attribute - key
               - value
               - optional y/n
               - included text is the description

In this way extending this is just a matter of defining new entries, and 
new keys for attributes.
Entries and avalon: attributes must be in the Avalon contract, the rest 
are defined by the developer, or using other internal standard.

Each xinfo file can have an xbundle file too, that maps paths to 
language and translation (see below), or it can be embedded directly in 
the xinfo file in a i18n entry.

<component-info>

    <component id="my-component"
               version="1.2.1"
               optional="FALSE">

       <attribute key="avalon:version"
                  value="1.2.1"

                  >This is a cool Service :-)</attribute>

       <attribute  key="avalon:lifestyle"
                   value="THREAD_SAFE"

                   >It must be threadsafe, or else....</attribute>

    </component>

    <context id      = "my-context"
             version = "1.1.0"
             optional= "FALSE">

       <attribute key="local:base"
                  value="java.io.File"

                  >The base from where all starts.</attribute>

       <attribute key="local:mode"
                  value="java.lang.Object"
                  optional="TRUE"

                  >Keeps the mode Object, used by my system.</attribute>
    </context>

    <service id="my-service"
             version="1.1.0"
             optional="FALSE">

       <attribute key="avalon:reference"
                  value="SimpleService"
                  optional="FALSE"

                  >This can be used to ...</attribute>
    </service>

    <dependency id="my-component"
                version="1.2.1">

       <attribute key="avalon:reference"
                  value="org.apache.cocoon.api.Transformer#1.1"
                  optional="FALSE"

                  >It depends on the transformer because...</attribute>
    </dependency>

</component-info>


<bundle>
   <item id="my-component">
     <attribute="avalon:reference">
       <text lang="IT">Ciao</text>
       <text lang="D">Hallo</text>
     </attribute>
   </item>
   ...
</bundle>

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message