Ok, i've updated my draft code at
https://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action
So for example:
FileObject file;
ActionManager actionManager = ...
Action[] actions = actionManager.getActions(file);
SvnCheckout checkoutAction = (SvnCheckout) actionManager.getAction(file,
Class SvnCheckout.class );
-- With SvnCheckout classes available:
checkoutAction.setRevision(55);
checkoutAction.execute();
-- Or without
ActionMetadata actionMetadata = new ActionMetadata( action )
Argument revisionArg = ... gets the right argument out of actionMetadata
...
revisionArg.setValue( new Integer(55) );
action.execute();
On Fri, 09 Dec 2005 15:23:16 +0000, "Yannick Menager"
<[EMAIL PROTECTED]> said:
> Been thinking about this, and you're absolutely right... My preference
> also has always been for the constrained approach, but my mind was a bit
> stuck on my 'remote vfs' usecase *sheepish grin*
>
> Actually nevermind what i said about having an optional loose API, but i
> think i have a much better idea:
>
> Require services to provide the meta-data information that could then be
> transfered and exposed to the client. Using either anotations on 1.5, or
> for example an xml file on older systems.
>
> i.e.:
>
> class SvnCheckout {
> /**
> * @@vfs.service-argument description='bla bla' optional='true'
> */
> public void setPort( int port ) {
> ...
> }
> }
>
> and of course provide API to easily access that information
> independently of it using 1.5 or a fallback method.
>
> On Fri, 09 Dec 2005 14:41:00 +0100, "Mario Ivankovits" <[EMAIL PROTECTED]>
> said:
> > Hi Yannick,
> > >>> 3) File Actions
> > >>>
> > > and allow the client VFS to
> > > remotely invoke those actions. In order to do that with that API, it
> > > would require the actually classes for all services to be in the
> > > client's classpath, which is a very bad approach.
> > I am definitely against having generic interfaces. If I write programs I
> > would like to compile my stuff and can be sure to have no syntax error
> > in it.
> >
> > Having interfaces like
> > setAttribute(String key, String value)
> > is against my wishes.
> >
> > If the value provided is syntactical correct (e.g. setAttribute("port",
> > "abd")) cant be checked during compile time, while
> > SvnCheckout.setPort(123) can be checked.
> > I am sure we find ways to call those services remotely without having
> > all the classes on the client. e.g by providing a RemoteService object
> > which uses reflection on the server side to configure the services then.
> >
> > The same idea I implemented in the *FileSystemConfigBuilder stuff. If
> > you e.g. have to process settings from an xml-file you can use the
> > DelegatingFileSystemObjectBuilder which uses (for sure rather
> > sophisticated) reflection to call the type safe implementations the.
> >
> > ---
> > Mario
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
