RE: runtime attributes

[Jon Tirsén <jo...@tirsen.com>]

> -----Original Message-----
> From: aslak.hellesoy@bekk.no [mailto:aslak.hellesoy@bekk.no] 
> Sent: den 19 november 2002 14:56
> To: ara_e_w@yahoo.com
> Cc: mpollack@speakeasy.net; james_strachan@yahoo.co.uk; jon@tirsen.com
> Subject: RE: runtime attributes
> 
> 
>  
> Hi!
> 
> (Sorry for sending HTML mail, I have a lame webmail client for Lotus >
Notes).
> 
> I'm delighted to hear that you have all decided to join forces on
this! I 
> 
> haven't read all messages in detail, but I still have some comments:
> 
> Consider the following @tags:
> 
> /**
>  * @simple we like to program
>  * @complex we="like" to="program" 
>  */
> 
> These are the two "legal" @tag formats in XDoclet/XJavadoc. It's
analog to 
> XML:
> 
> <simple>we like to program</simple>
> <complex we="like" to="program"/>
> 
> The complex format is used more by XDoclet plugins than the simple
format.
> The XJavadoc API supports both formats though.
> 
> Because of this similarity with XML, the XDocleteers say that 'we' and
> 'to' > > are "tag attributes" (aka tag parameters, but attributes is a
better name), just > like in XML. It is not the same as "attributes" in
the .Net terminology. In .Net > terminology you could think of them as
"attribute attributes" ;-).
> 
> The main reason that XDoclet is using tag attributes is to be able to
group
> related data. For example, an EJB might have several @ejb.finder tags,
and it's
> handy to be able to group all data related to one finder in the same
tag, 
> separated as tag attributes.
> 
> The question is: How fine-grained should the commons-attributes API
be? If you 
> specify a tag with tag attributes as above, what would the
commons-attributes 
> API give you?
> 
> I think that it should give back the raw text, and not try to deal
with internal 
> semantics of the @tag content. That should be the responsibility of a
layer that 
> sits on top of commons-attributes (and these layers should not be
maintained by 
> jakarta, but by applications using the commons-attributes API).

Okay, this is basically the Nanning-approach. Commons-attributes is a
low-level API, higher-level APIs are built on top of it. Well, it's okay
with me, but I don't think Ara would agree... This is not really what
we've been discussing so far.

> This way people can define their own @tag semantics. Who knows, maybe
someone 
> wants:
> 
> /**
>  * @foo <hip hop="wont">stop</hip>
>  */
> 
> It should be possible. The commons-attributes API should (the way I
see it) only 
> be an API to access the raw text in @tags at runtime. Then people can
treat that 
> raw text the way they want. XDoclet will parse it into key="value"
pairs.

Regardless of wheather we will build a higher level API or a lower-level
one we must support this. We should not mandate the actual formats of
the raw text.

> Further we need to define:
> 
> o An SPI API (interfaces only) for the attributes compilers
(XDoclet/XJavadoc,
> QDox).
> o A contract that defines attribute inheritance semantics.

Couldn't this also be built on top of the low-level API? If we have a
low-level API we shouldn't be doing any of this either, since it really
is implementable on top of a low-level API.

> o A test suite for the SPIs.
> 
> Aslak
> 
> What are your thoughts on this?

The biggest problem I can see with this is that it will be much harder
to implement runtime-validation. If we can have some kind of pluggable
mechanism to the compiler that might work anyway. But it will be much
less object-oriented. With attribute-objects validation will be much
more natural.

Once, again. We need to agree on this. If we want a low-level API I
think we should use the Nanning-approach which is the simplest possible
low-level API there is. A higher-level API will mandate a lot of things
that all users of such an API may agree with. This will create other
implementations and we still don't have the unified API that we were
looking for in the beginning.

For me, at the moment, I'm leaning more towards a lower-level API that's
open for adding higher-level support in later releases (such as
compile-time validation and so on).


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [?][SUBMIT] FileSystem.java

[Adam Murdoch <ad...@apache.org>]

On Wed, 20 Nov 2002 07:11 pm, Jeff Varszegi wrote:

> Is work being done on VFS right now?  

Yes.  A little slowly, perhaps, but it is happening.

> Can I help?  

Yes, definitely.  Did you have anything particular in mind?  Otherwise, If 
you're looking for things to do, there's a bunch of stuff in the todo list 
(in cvs - haven't updated the web site yet).  Either way, patches are most 
welcome.

> It seems like something
> I could really sink my teeth into.  Are there plans to do nice stuff like
> support agglomerated file systems, so that we can support federated
> namespaces?  

Absolutely.  Have a look at the todo list.

> Has VFS already been superseded by something else?  

Don't think so.  Even if it were, a little competition never hurt.

> I did poke
> around a lot to find this out, but I am still not sure.
>
> Jeff
>
> P.S. I was wondering why a putFile(FileObject file) appears in the
> AbstractFileSystem class, but not in the interface FileSystem.  I noticed
> some other stuff too.

Because clients of FileSystem never need to 'put' files; The file system is 
responsible for creating FileObject instances, so clients only ever 'get' 
files.  AbstractFileSystem maintains a cache of FileObjects, and the 
putFile() method is there for subclasses to add files to that cache.

-- 
Adam

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [?][SUBMIT] FileSystem.java

[Henri Yandell <ba...@generationjava.com>]

On Wed, 20 Nov 2002, Jeff Varszegi wrote:

> I had this class lying around and thought I'd post it.  I just took a
> look at the FileUtils class (didn't check out the one in Excaliber
> yet), but I think that there're lots of difference between this class
> and FileUtils.

Excaliber's io is in io now.

> 'FileSystem' is a simple standalone class for dealing with a regular
> ol' file system.  You can set a root directory and perform operations
> on files using relative paths if you wish.  I've found it pretty
> useful in the past.  It supports some things like OS-agnostic file
> copying and searching, simple wildcard file/directory searches, etc.
> If you have time, please look it over and see if some of it sparks a
> thought or might be useful.  I keep it around in my ragtag private
> util package.

Sounds useful. Will try to take a peek.

Hen




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[?][SUBMIT] FileSystem.java

[Jeff Varszegi <jv...@yahoo.com>]

I had this class lying around and thought I'd post it.  I just took a look at the FileUtils class
(didn't check out the one in Excaliber yet), but I think that there're lots of difference between
this class and FileUtils.  

'FileSystem' is a simple standalone class for dealing with a regular ol' file system.  You can set
a root directory and perform operations on files using relative paths if you wish.  I've found it
pretty useful in the past.  It supports some things like OS-agnostic file copying and searching,
simple wildcard file/directory searches, etc.  If you have time, please look it over and see if
some of it sparks a thought or might be useful.  I keep it around in my ragtag private util
package.

Is work being done on VFS right now?  Can I help?  It seems like something I could really sink my
teeth into.  Are there plans to do nice stuff like support agglomerated file systems, so that we
can support federated namespaces?  Has VFS already been superseded by something else?  I did poke
around a lot to find this out, but I am still not sure.

Jeff

P.S. I was wondering why a putFile(FileObject file) appears in the AbstractFileSystem class, but
not in the interface FileSystem.  I noticed some other stuff too.

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

[configuration + lang] Question + suggestion

[Jeff Varszegi <jv...@yahoo.com>]

Is the Configuration stuff used anywhere?  Just curious.  I was looking at the code for
BaseConfiguration and was thinking that it should convert between numeric types (which it
doesn't).  For instance, if getFloat() is called with a key that is mapped to an Integer object,
it won't convert the value to a float and return it, etc.  It should probably work more like Java
w/ respect to widening/narrowing numeric types, don't you think?

In the XMLProperties class I sent to the list a short while ago I had a static inner class called
PropertyConverter that the enclosing class used to do data-type conversions.  Believe you me, I'm
not touting the virtues of that class, but I think it would be good to do the same thing with
Configuration so the code is reusable, and maybe put it in Lang.  Just a simple ute class to do
simple data-type conversion.  Right now what's available is scattered around.  What do you think?

Jeff

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: runtime attributes

[Jon Tirsén <jo...@tirsen.com>]

> -----Original Message-----
> From: Ara Abrahamian [mailto:ara_e_w@yahoo.com] 
> Sent: den 19 november 2002 21:45
> To: 'Jon Tirsén'; aslak.hellesoy@bekk.no
> Cc: mpollack@speakeasy.net; james_strachan@yahoo.co.uk; 
> 'Jakarta Commons Developers List'
> Subject: RE: runtime attributes
> 
> 
> Well then let's see what happens if someone serializes a 
> ClassMetaData with Nanning, and reads it with an 
> Xdoclet-based runtime api. Assume Nanning uses a different 
> syntax than xdoclet and we just store the raw text. Now the 
> Xdoclet runtime reads it and can't understand it! It can 
> happen quite easily, maybe a third party uses Nanning and not 
> Xdoclet like you do? So the lowest denominator is 
> getProperty/setProperty and no raw text, no syntax, just the api.

Yeah, I've been thinking about this too. This is one of the main reasons
why commons-attributes should be quite high-level. I'm leaning more
towards Aras way at the moment, if we just dump the serialization.

> So we can have different parsers, different syntaxs, but as 
> far as the api is concerned there's no difference for the 
> user of the api.

Yeah, the parsers and the runtime-plugin can do whatever they like if
they implement the API. So an example: A library like OJB mandates the
following: I need to have an attribute of type
org.apache.jakarta.ojb.FieldMapping on each field and an attribute of
type org.apache.jakarta.ojb.ClassMapping on each class. I don't care how
you do it, and what parser you're using to do it, I just need to access
those attributes through the commons-attribute-API. This is how you do
it using the default-parser: (example code).


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: runtime attributes

[Ara Abrahamian <ar...@yahoo.com>]

> > /**
> >  * @simple we like to program
> >  * @complex we="like" to="program"
> >  */
> >
> > These are the two "legal" @tag formats in XDoclet/XJavadoc. It's
> analog to
> > XML:
> >
> > <simple>we like to program</simple>
> > <complex we="like" to="program"/>
> >
> > The complex format is used more by XDoclet plugins than the simple
> format.
> > The XJavadoc API supports both formats though.

It's easy to support @simple attributes. Just add a getAttributeText
method, like xjavadoc's XTag.getAttributeValue() method. Not a big deal
at all imho.

> > The question is: How fine-grained should the commons-attributes API
> be? If you
> > specify a tag with tag attributes as above, what would the
> commons-attributes
> > API give you?

Well we don't mandate any syntax. Some might prefer @blabla a="a"
syntax, someone might prefer @blabla ("a") or @blabla a("a"). The
runtime api doesn't deal with the syntax. The contract is simple: a
class meta data, with attributes, and attributes have properties, we can
query the attribute and its properties. The syntax is irrelevant.

> > I think that it should give back the raw text, and not try to deal
> with internal
> > semantics of the @tag content. That should be the responsibility of
a
> layer that
> > sits on top of commons-attributes (and these layers should not be
> maintained by
> > jakarta, but by applications using the commons-attributes API).

I don't think we need layer for this simple task! It's just a get/set.

> > It should be possible. The commons-attributes API should (the way I
> see it) only
> > be an API to access the raw text in @tags at runtime. Then people
can
> treat that
> > raw text the way they want. XDoclet will parse it into key="value"
> pairs.

Well then let's see what happens if someone serializes a ClassMetaData
with Nanning, and reads it with an Xdoclet-based runtime api. Assume
Nanning uses a different syntax than xdoclet and we just store the raw
text. Now the Xdoclet runtime reads it and can't understand it! It can
happen quite easily, maybe a third party uses Nanning and not Xdoclet
like you do? So the lowest denominator is getProperty/setProperty and no
raw text, no syntax, just the api.

So we can have different parsers, different syntaxs, but as far as the
api is concerned there's no difference for the user of the api.

> > o An SPI API (interfaces only) for the attributes compilers
> (XDoclet/XJavadoc,
> > QDox).
> > o A contract that defines attribute inheritance semantics.

I think what we already have in xrai is ok. Commons-attributes will have
some test cases for attribute inheritance for example, qdox or xjavadoc
based runtimes will be tested against those test cases.

> > o A test suite for the SPIs.

Yes!

Ara.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>