Hi Steve,
Sorry to be taking so long to reply - other work intervened. You are in a
better position to decide what is more feasible to implement and support, as
far as file actions go. On further reflection I think that perhaps a generic
action component that iterates the action over a list of parameters would be
useful for more than just working with a list of files. With files, you would
just need to combine it with Files or FilesCompound, ensuring that the latter
deploys first (isn't that the default behavior when two components follow each
other in a compound?)
A use case would look something like this:
DoStuffWithFiles extends Compound {
files extends Files {
...
}
doStuff extends Iterate {
params PARENT:files:fileList;
action extends {
...
}
}
}
Regards,
Dmitry
-----Original Message-----
From: Steve Loughran [mailto:[email protected]]
Sent: Tuesday, November 09, 2010 6:06 PM
To: Dmitry Epstein
Cc: [email protected]
Subject: Re: [Smartfrog-users] Deleting multiple files?
On 08/11/10 10:30, [email protected] wrote:
>> -----Original Message-----
>> From: Steve Loughran [mailto:[email protected]]
>> Sent: Monday, November 01, 2010 5:31 PM
>> To: Dmitry Epstein
>> Cc: [email protected]
>> Subject: Re: [Smartfrog-users] Deleting multiple files?
>>
>>
>>>
>>> Yes, I was aware of SelfDeletingFile. I was thinking of perhaps
>> adding deleteOnExit attribute to the Files component, or patching
>> together a new component, based on Files.
>>>
>>
>> OK. I'm just checking in a DeleteFile component that does the delete
>> operation but is more helpful on a failure, even security exceptions
>> are caught and turned into errors.
>>
>> I also had a quick scan and cleanup of the test of that code, again
>> checking it in as we speak. Looking at that code, the target for
>> modification would be to subclass FilesCompoundImpl and have a child
>> DeleteFiles which would call FilesCompoundImpl.sfStart(), take that
>> list of files and do a best effort attempt at deleting them, tracking
>> which ones couldn't be deleted and adding that up to some results
>> which could be reported or turned into an error.
>
> Speaking of files, a useful workflow component would be one that iterates
> over a list of files, i.e. performs a parameterized execution of its action
> sub-component, where the parameter is a path-name from a Files component.
I had an opportunity to sit with the IDE and the SF code in front of me
yesterday, and now have an uncommitted change that makes the FilesCompoundImpl
component a subclass of EventCompoundImpl, which makes it one very short
distance away from having an action compound deploy.
But that gets very confusing as to what contains files and what contains the
action.
What that parent change does do is make the FilesCompound a workflow component
that can read the attributes saying what to do after building the list, and it
would be trivial to add a target attribute to specify which component to attach
the list.
> Or perhaps a more general component that iterates over any given vector, with
> a child component specifically for files.
Probably simplest to deploy the action once the files have been gathered.
>
> I know this would be useful for my test designs.
I think I understand. So, what is most usable/easy to test, document and
understand?
1. -tweak FilesCompoundImpl, add a FilesActionCompoundImpl that deploys
the action after building up the filelist, skipping that action until
then, the actions would have to take a reference to something that can
serve up the file list, either a simple attribute/list or a component
that can return the list of files over RMI.
2. have FilesCompoundImpl support workflow attributes and a target
attribute, add the ability to write its filelist to a destination (as
both a list of strings and a single path.separator separated string.)
both of these would be backed by some FilesOperations which would be
workflow components. I'd start with
DeleteFiles - delete any, do a best effort skip all missing files, log
failures and continue.
ExistsFiles - check the files all exist (or don't exist, we'll use that
for testing DeletesFiles)
Other actions: copy, scp, etc, are feature creep.
What do you think, (1) or (2)? I think (2) is more generic and would
work in more places. Also trying to test and debug the workflow
components is no fun, believe me, especially once you start encountering
odd race conditions with termination events coming in while you are
starting up:
http://jira.smartfrog.org/jira/browse/SFOS-1510
http://jira.smartfrog.org/jira/browse/SFOS-1526
-Steve
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Smartfrog-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smartfrog-users
