You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/20 16:02:12 UTC
[phoenix] Resprucing Blockinfo
Hi,
I finally got around to resprucing BlockInfo and decided to remove the
<meta/> section. It wasn't being used and wasn't really that useful ;) It
basically included a lot of meta information that was arbitrarily associated
with Blocks supposedly to use in GUI configuraor but not really that useful.
However I added another section <block/> that replaced some of the
functionality. Currently it looks like
<block>
<version>1.0</version>
</block>
However I have been thinking about allowing another sub-element <classname/>
that gave classname of Block. However this is kinda redundent because the
location of BlockInfo automatically specified classname of block. ie If a
Blockinfo file is at "com/biz/blocks/Foo.xinfo" we automatically know that
the classname of the block is com.biz.blocks.Foo.
So my question is; What do you think - should we require this subelement or
should we determine block classname based on location of BlockInfo ??
BTW: I have been tinkering with XML Schema support for configurations inside
the <block/> element and may get a chance to implement it in the next few
months (finally - yay!!).
BTW2: This is all backwards compatible ... it just issues warnings if you
don't specify new section and ignores the old section.
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Resprucing Blockinfo
Posted by Peter Donald <do...@apache.org>.
On Fri, 21 Sep 2001 13:48, Eung-ju Park wrote:
> I think determine block classname based on location of BlockInfo is batter.
ok.
> Is there any case xinfo and class exist difference place?
Not at this stage.
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] Resprucing Blockinfo
Posted by Eung-ju Park <co...@isoft.co.kr>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Thursday, September 20, 2001 11:02 PM
Subject: [phoenix] Resprucing Blockinfo
> Hi,
>
> I finally got around to resprucing BlockInfo and decided to remove the
> <meta/> section. It wasn't being used and wasn't really that useful ;) It
> basically included a lot of meta information that was arbitrarily
associated
> with Blocks supposedly to use in GUI configuraor but not really that
useful.
>
> However I added another section <block/> that replaced some of the
> functionality. Currently it looks like
>
> <block>
> <version>1.0</version>
> </block>
>
> However I have been thinking about allowing another sub-element
<classname/>
> that gave classname of Block. However this is kinda redundent because the
> location of BlockInfo automatically specified classname of block. ie If a
> Blockinfo file is at "com/biz/blocks/Foo.xinfo" we automatically know that
> the classname of the block is com.biz.blocks.Foo.
>
> So my question is; What do you think - should we require this subelement
or
> should we determine block classname based on location of BlockInfo ??
I think determine block classname based on location of BlockInfo is batter.
Is there any case xinfo and class exist difference place?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org