Who should upload files?

[Bob Silverberg]

I was just having an interesting conversation with John Whish about where we think file uploads should occur in an OO application.  We are both processing our file uploads using a Filesystem object (FSO), which we both agree should be responsible for doing the actual uploads, and simply returning data about the upload to the caller (e.g., success, filename, etc).

We are also both currently call that FSO from a Service.  We were discussing whether to move that logic into the Business Objects (BOs) themselves.  I tend to try to keep my services dumb, and to push logic into the BOs whenever possible, so this seemed like a candidate, but then we discussed the fact that the BO shouldn't need to know that a file upload has to occur at all.  Maybe one day the file won't be uploaded, maybe it will come from another source altogether. So we decided that the BO shouldn't know about the file upload, and therefore shouldn't be responsible for asking the FSO to do the upload, so that brings us back to the service.

But then we discussed the fact that the file upload isn't really a model concern at all.  That the model should be independent of the client that's calling it. So really the service shouldn't need to know that a file has to be uploaded either. So that leaves the controller.  Again, we try to keep our controllers reasonably dumb and lean, so although this seemed to be the place to do it in theory, we didn't like the idea of having to add a bunch of code into each controller method that involved a file upload.

So, by now you're probably wondering, why the heck is he writing this to the Model-Glue group. Well, we figured that the job of uploading files really belongs in the controller, and the controller is an extension of the MVC framework, so maybe this really should be the job of the MVC framework.  The implementation that we imagine would involve convention, and would basically be something along the lines of:

1. Framework receives request.
2. Framework takes input data (i.e., form and url scope) and puts them into event object.
3. Framework looks for files to be uploaded - could be done via a convention on naming of form fields (or maybe it's possible to look at the content of a form field to determine if it contains a file?)
4. Framework attempts to upload said files and places metadata about the uploads (e.g., success, filename, etc) into the event object
5. Framework then passes control to the controller for the event, which now has access to all of the data, and the files are already uploaded.

Of course this isn't a simple matter.  What happens, for example, if one of the uploads fails?  Also, it might be nice if this could somehow be a separate component that could be injected into the request lifecycle, rather than adding it to the core of the framework itself.

So this discussion raises a few questions for John and I:

1. Is it possible to do something like this without touching the core files of MG?  Is there a plugin point for something like this?
2. Is this even a good idea at all?  What thoughts do people have about where this upload should occur?
3. If it is a good idea, what ideas do people have about how to implement it?  Currently our thinking is to base it on convention, so it would happen automatically.

Thanks for taking the time to read this, and thanks for any thoughts you may have.  Perhaps I'll see some of you tonight/tomorrow in Raleigh.

Cheers,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Dan Wilson]

Interesting thought and I'd be happy to have a good discussion on it. I've always felt uploading files in an OO manner (especially with an MVC framework) wasn't as elegant as it could be.


DW

--
“Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.”

Guillaume Apollinaire quotes

[Jared Rypka-Hauer]

I kinda disagree with the idea that a service shouldn't know what kind
of request it's responding to. That's an awfully broad notion. I do
agree that file uploads aren't the concern of the business objects
themselves, which leaves us with 2 options: putting the functionality
in the framework itself or building a portion of the service layer to
handle it.

Personally I think that things like file uploads, unit conversion
(i.e. Fahrenheit to Celsius), validation and other things that aren't
model concerns, but are still required by the application, belong in
the service layer. In fact I would go so far as to say that this is
the ideal situation for a SERVICE to actually fit its description. The
term "service" implies action, something that provides functionality
that you don't have yourself. A diaper service, an auto repair
service, a file upload handling service, a shipping service... things
that don't help describe the business rules of the domain but are
required for the full functionality of the application to come to
fruition.

This becomes especially obvious if you think of CF tags as services,
especially the ones with action="" attributes that have several
options, as services themselves. An FTP service makes sense because it
handles all the FTP operations for an application. A mail service
makes a great deal of sense and analogizes 1:1 to real-world
"services" (i.e. USPS and FedEx) that we use every day. Yet another
example is the ColdFuson indexing and search service which even gets
installed separately and runs _as a service_ on a machine that
processes requests _for that service_. I don't think you could
possibly find more appropriate examples of what a "service layer"
should do.

Consider also the fact that the file upload itself is purely a
function of the webserver and CF and that you're not really processing
an "upload" but, essentially, a copy operation from the temp directory
to a permanent location. The server takes care of receiving the data
from the HTTP header and turning it into a file on disk. I don't see
this being a framework-level operation any more than logging a user
into a website is. There is, however, a solution to this problem
that's been part of MG for years and would pretty much satisfy the
needs and objections of everyone.

I wouldn't mind seeing an actionpack to do this, but adding it into
the framework is pretty much a complete departure from the charter of
Model-Glue (which is to provide a connection between HTML pages and a
model). Even more so when you start talking about convention-based
operations. Model-Glue has, and I hope always will be, configuration-
based (seriously, if you want a convention-based framework, there are
2 really good ones out there). Adding in an actionpack allows this
functionality to be provided so that you could do something like this:

<event-handler name="files.upload">
<broadcasts>
<message name="uploadFile">
<value name="formField" value="someFooFile" />
<value name="destination" value="c:\someFooPath" />
<!-- add in the other cffile attributes if you want -->
</message>
</broadcasts>
<results>
<result name="success" do="files.goodJob" />
<result name="fail" do="files.youSuck" />
<result name="epicFail" do="files.omgDoYouSuck" />
</results>
</event-handler>

Then again, you don't really need an actionpack to make that work, and
you could, if you wanted, stuff all that crap in the controller. Or
you could build a nice, abstracted FileService that any OO app could
use and have the controller lean on that to do the heavy lifting
(which is the relationship that controllers and services are supposed
to have in the first place). Either way, it would work.

And, as always, keep in mind that it's all opinion and nobody is ever
right, they're just less wrong sometimes. ;)

J

On Oct 16, 2009, at 9:47 AM 10/16/09, Bob Silverberg wrote:

> I was just having an interesting conversation with John Whish about
> where we think file uploads should occur in an OO application. We
> are both processing our file uploads using a Filesystem object
> (FSO), which we both agree should be responsible for doing the
> actual uploads, and simply returning data about the upload to the

> caller (e.g., success, filename, etc). ...

[Bob Silverberg]

Jared,

You make some great points about what a service is and should be able to do.  I think I was a bit vague in my explanation of a service in this context, because it sounds like what you are suggesting is actually similar to what we are talking about:

On Fri, Oct 16, 2009 at 11:46 AM, Jared Rypka-Hauer <armcha...@gmail.com> wrote:

Then again, you don't really need an actionpack to make that work, and
you could, if you wanted, stuff all that crap in the controller. Or
you could build a nice, abstracted FileService that any OO app could
use and have the controller lean on that to do the heavy lifting
(which is the relationship that controllers and services are supposed
to have in the first place). Either way, it would work.

When I talked about a Filesystem Object (FSO) I'm really talking about a FileService like what you are describing (I'm just not using the term Service), so we _are_ talking about using a service to actually do the uploads, and the only question was: who should be calling that service.  From your examples it looks like you agree that it should be the controller, either explicitly or via an action pack.

I was a bit vague when I used the term Service earlier.  I meant a domain-specific service, like a UserService or a ProductService.  Imagine that we have a ProductService with an update() method that is responsible for accepting input from a controller and then it does everything that needs to be done with that info (e.g., validation, persistence, etc.).  The question was, should that ProductService also be responsible for asking the FileService to do the uploads, or should that have already been done by the controller prior to calling the ProductService.

So, where do you stand on that question?  It sounds to me like you feel that the controller should tell the FileService to upload the files, rather than having the ProductService tell the FileService to upload the files.  Is that accurate?

--
Bob Silverberg
www.silverwareconsulting.com

[Jared Rypka-Hauer]

I see where you're going... and yeah, I do agree that the controller
should tell the file service to upload the file as part of the request
processing cycle. If you have an event like product.add which includes
adding an image for that product, I think the event should tell the
file service to manipulate the uploaded file and make the path to the
file in its permanent location available for the product service to
store. The product service shouldn't concern itself with files... it
should concern itself with product related behavior and the data
required for that behavior to be enacted.

So yeah, I guess we're in less disagreement than I thought. :)

J

[John Whish]

Thanks for your thoughts on this Jared and Dan. I'm afraid I don't use
Model Glue (another thing on the list to learn!) but think this
conversation could apply to any MVC framework.

It seems that we all share a similar philosophy on this. Hope you guys
can meet up at CFinNC. I'd be interested to see how this progresses.
:)

- John

[Bob Silverberg]

Dan and I (and Shannon and Josh) discussed this a bit at CFinNC (more accurately on the drive to the airport from CFinNC). I realized that one solution is quite simple:

1. Create a utilitiy controller - let's call it UtilController.
2. The UtilController will listen for a message "needsFileUpload".
3. That message will accept an argument which will specify the name of the form field that contains a file.
4. The controller method invoked via the message will then upload the file (using a separate FileUploader component), and create a structure containing metadata about the upload (e.g., success, serverfilename, etc.), and place that structure into the Event object. It could create an object instead of a structure, but that might be overkill.
5. For any event that you know requires a file upload, you add a needsFileUpload message to the event.

This would allow for "automatic" file uploads, with all of the code having to do with file uploads being encapsulated in the UtilController and the FileUploader.

This seems like a pretty decent approach, and is something that a developer could implement themselves without having to worry about MG doing anything for them.  This also follows MG's approach of configuration rather than convention.  You would now have a map in your MG.xml file which shows which events expect files, so there's some value in that.

Personally I'd still prefer to be able to have it happen automatically (i.e., without having to add a message and argument each time I need a file upload as part of an event), and we discussed that as well. We discussed the possibility of using conventions (e.g., form field names) and also the possibility of detecting file uploads automatically and responding to them.

One idea that was discussed was the possibility of adding a configurable feature like this to MG. As this does relate to the controller part of the code, and it's a common requirement, there might be some value in adding such a feature to MG. The idea is that some sort of FileUploadDetector could be added to the MG request lifecycle, and folks could choose to implement it however they felt.  When the FileUploadDetector does detect a form field containing a file, it would then automatically upload it using a separate FileUploader object, which could be configured via Coldspring, and would place the metadata for the file upload into the Event object.

The default FileUploadDetector would not detect any files, and therefore no files would ever get uploaded automatically. If one wanted to turn on the feature, one would specify a different FileUploadDetector component that uses an algorithm for detecting files. Perhaps one component would look for fieldnames starting with "file_". Perhaps another would look for any field that contains a file (I have an untested algorithm for that). Perhaps yet another would respond to messages in the MG.xml file (to allow for configuration).  The point is that if a developer wanted to use conventions to implement the algorithm they could, and if one wanted to use configuration they could. And if one didn't want to have anything to do with this crazy auto-file-uploading scheme, well they'd just accept the default behaviour. Nobody would be forced to do it a certain way, but anyone would be able to do it however they pleased.

I think that this would be fairly easy to implement, and I'd be willing to take a crack at it, but first I'd like to know what others think of the idea.  Does it sound like a good idea? A bad idea? A crazy idea? Any other takes on approaches to the same issue?

Thanks for listening,

[Chris Blackwell]

Bob,

I like, and use something along the lines of the first method you describe of broadcasting a needFileUpload message with an argument defining the filefield value, although I'm handling the upload directly in the controller rather than in a separate FileUploader component.  

However I'm not convinced there's a need to go to the lengths you describe to handle file uploads automatically.  This just sounds like an actionpack to me. Surely all thats needed is a controller with a method to detect uploads, handle them (possibly using supporting cfc's like an UploadDetector or FileUploader) then set the metadata into the event, which is fired onRequestStart.

Chris

2009/10/20 Bob Silverberg <bob.sil...@gmail.com>

[Bob Silverberg]

That is a very good idea.  Honestly, I haven't used MG much in quite awhile. Although I poke my nose into the framework code every now and then I am kinda rusty from a user perspective.  I didn't even think about simply using onRequestStart to do this - duh.  I think that would accomplish just what I'm talking about, and different actionpacks could be made available with different implementations.  I suppose the only advantage to baking it into the framework would be that developers wouldn't need to locate and install an actionpack as a separate step. Is there some sort of repository for MG actionpacks?

Cheers,
Bob

On Tue, Oct 20, 2009 at 4:20 PM, Chris Blackwell <ch...@team193.com> wrote:

Bob,

I like, and use something along the lines of the first method you describe of broadcasting a needFileUpload message with an argument defining the filefield value, although I'm handling the upload directly in the controller rather than in a separate FileUploader component.  

However I'm not convinced there's a need to go to the lengths you describe to handle file uploads automatically.  This just sounds like an actionpack to me. Surely all thats needed is a controller with a method to detect uploads, handle them (possibly using supporting cfc's like an UploadDetector or FileUploader) then set the metadata into the event, which is fired onRequestStart.

Chris

--
Bob Silverberg
www.silverwareconsulting.com

[Chris Blackwell]

I'm not aware of an actionpack repo, and i'm not sure if any of the exisint actionpacks have been tested against Gesture.  But seems like there probably should be one!

By the way, just read your blog post and the regex breaks on windows because you need to escape the backslashes,  you need 

REFindNoCase("^" & replace(tempDir,"\", "\\", "all"), form[fld])

Chris

2009/10/20 Bob Silverberg <bob.sil...@gmail.com>

That is a very good idea.  Honestly, I haven't used MG much in quite awhile. Although I poke my nose into the framework code every now and then I am kinda rusty from a user perspective.  I didn't even think about simply using onRequestStart to do this - duh.  I think that would accomplish just what I'm talking about, and different actionpacks could be made available with different implementations.  I suppose the only advantage to baking it into the framework would be that developers wouldn't need to locate and install an actionpack as a separate step. Is there some sort of repository for MG actionpacks?

[Chris Blackwell]

I just took a stab at this, in a very quick and dirty fashion. 

Stick that in a controller and fire it onRequestStart and you're good to go.

<cffunction name="handleUploads">

<cfargument name="event" />

<cfset var tempDir = getTempDirectory() />

<cfset var regex = "^" & replace(tempDir,"\", "\\", "all") />

<cfset var i = "" />

<cfset var uploads = structnew() />

<cfset var result = "" />

<cfset var tempFile = "" />

<!--- i think its probably ok to access FORM directly here... --->

<cfloop collection="#form#" item="i">

<cfif REFindNoCase(regex, form[i])>

<cftry>

<cfset tempFile = createuuid() />

<cffile action="upload" filefield="#i#" destination="#tempDir#/#tempFile#" result="result" />

<cfset uploads[i] = result />

<cfcatch>

<!--- you might wanna log this error or take some action here --->

</cfcatch>

</cftry>

</cfif>

</cfloop>

<cfset event.setValue("uploads", uploads) />

</cffunction>

2009/10/20 Chris Blackwell <ch...@team193.com>

[Bob Silverberg]

Cool. That looks like it would do the trick.  Thanks for taking the time to do that!

--
Bob Silverberg
www.silverwareconsulting.com

[Chris Blackwell]

No probs, I may well use this myself in the near future!

2009/10/20 Bob Silverberg <bob.sil...@gmail.com>

[denstar]

On Tue, Oct 20, 2009 at 2:35 PM, Chris Blackwell wrote:
> I'm not aware of an actionpack repo, and i'm not sure if any of the exisint
> actionpacks have been tested against Gesture.  But seems like there probably
> should be one!

Long ago, in a far away land, I helped someone hack up the RIAForge
code for use as a framework actionpack type deal.

I cannot even remember for whom I was providing help, nor the URL, currently.

Anyways, I've got a metric crapload of actionpacks that are being used
with Gesture. Just none of the ones that came with it.

Dunno if anyone would really find them that interesting, they're
nothing special. The ones that are actually useful in the lot are
things like G11n, exception handling, and maybe the SVN or jExcelAPI
ones.

Eh.

As for convention for file uploads... well, it's fine, but I'll be
honest, and say that anything that does uploading out o' the box
scares the bigeeziz outta me. At least if it's enabled by default.

You have no idea how many times I said on the FCKEditor forums we
shouldn't be shipping the connectors all in there like that... I
mean, it was like, at least twice. :)p

--
Great persecutors are recruited among martyrs whose heads haven't been cut off.
Emile M. Cioran

[Dan Wilson]

It would be good to take a look at the actionpacks you have Denny.  If you would be of the mind and position to  make them available,, we'd love a look.

Model-Glue is of the people, by the people and for the people.



DW

[Bob Silverberg]

I agree that uploading files by default can be dangerous, but that's really one of the valuable things about centralizing the code that does it.  The code that does the uploading could be designed so that all files go into non-web accessible locations, and could also include any other security measures needed.  If it were designed to be secure and all files were uploaded using it, there'd be no chance of someone accidentally forgetting to do it properly.

On the actionpack front, why not just suggest that people upload actionpacks to RIAForge, and make sure that they have MG:ActionPack (or some such) in the name.  Then the MG team can advertise that fact and people will be able to find them.

On Tue, Oct 20, 2009 at 5:04 PM, denstar <vallia...@gmail.com> wrote:

--
Bob Silverberg
www.silverwareconsulting.com

[Chris Blackwell]

2009/10/20 denstar <vallia...@gmail.com>

As for convention for file uploads... well, it's fine, but I'll be

honest, and say that anything that does uploading out o' the box
scares the bigeeziz outta me.  At least if it's enabled by default.

I completely agree.  The example function i posted to handle any uploaded files really isn't suitable to be enabled site-wide.  I'd probably only use it in an authenticated area of my site, like the admin, and then only if file uploads happened in a lot of places in the code.

Chris

[Jared Rypka-Hauer]

I think Bob's got a bad case of ColdBoxitis... ;) "put everything in
the 'Box, and I mean EVERYTHING!!"

You gotta know I'm teasing, yeah? Seriously...

Anyway, as for a respository, AFAIK the only repository of actionpacks
is in the Model-Glue SVN repo at http://svn.model-glue.com/trunk/modelglueactionpacks
if that's what you're looking for. Other than that there aren't
really any other sites that have an actionpack library. My suggestion?
Start putting MG actionpacks on RIAForge.

And, redundantly and for the record, my opinion is that Model-Glue is
a configuration-based framework and there are plenty of convention-
based frameworks out there. I think that deliberately adding
exceptional cases to anything is as bad an idea as there is, and that
one broadcast isn't an intolerable quantity of work. While I
understand the arguments for it, I would dispute the notion that it's
actually less work in a big-picture analysis and I would only support
a configuration-based solution if one were ever to be provided as an
actionpack. MG's vision has never been to supply ancillary services
like this except thru the actionpack API and I don't think there's any
reason to distract the team with things that don't apply to the
framework's vision.

In the end, someone who knows MG comes to an MG application expecting
to follow the application execution path thru the config file. If I
were to end up supporting an app where someone added something like
this convention-based approach to file uploads I'd be... umm...
well... OK, to be honest? Pissed. Why? Because it totally defeats the
shining truth that is Model-Glue: consistent, self-documenting,
obviated application operation and architecture. Hiding things in
oRS() just makes application support more difficult.

All opinions expressed here are solely the property of the expresser
and not to be taken in any other way. :)

J

[denstar]

On Tue, Oct 20, 2009 at 3:12 PM, Bob Silverberg wrote:
> I agree that uploading files by default can be dangerous, but that's really
> one of the valuable things about centralizing the code that does it.  The
> code that does the uploading could be designed so that all files go into
> non-web accessible locations, and could also include any other security
> measures needed.  If it were designed to be secure and all files were
> uploaded using it, there'd be no chance of someone accidentally forgetting
> to do it properly.

Now this is what I'd call an actionpack! Takes care of the repetitive
drudgery of coding the stuff up for each application handily.

Set a few variables-- wham-bam-thank-you-ma'am!

> On the actionpack front, why not just suggest that people upload actionpacks
> to RIAForge, and make sure that they have MG:ActionPack (or some such) in
> the name.  Then the MG team can advertise that fact and people will be able
> to find them.

Yes, I reckon we're in agreement on this front. I really liked the
idea of frameworkforge (IIRC), as we were going to aim at supporting
multiple frameworks, yadda yadda.

To be useful, I think my stuff would need a bit of refactoring, as
well as testing on ACF, as I'm Railo to the hilt.

RIAForge it is tho!

--
In every man sleeps a prophet, and when he wakes there is a little
more evil in the world.
Emile M. Cioran

[Dennis Clark]

While setting up separate RIAForge projects for each actionpack is fine, I would also like us to have a collaborative MG actionpack project. I also need an excuse to get my hands dirty with Git. What do you guys think of creating a GitHub respository for MG actionpacks? I see Bob is already making a name for himself as a source of info for getting started with Git, so maybe he wouldn't mind setting up the GitHub repository for us?

Cheers,

-- Dennis

"One of these days I'll get myself a real .signature" - Me

[Bob Silverberg]

I wouldn't mind at all, but I think someone from the team should own it.  I think for a project like MG it would make sense for someone to have ultimate control over what gets merged into the "master" repo. 

--
Bob Silverberg
www.silverwareconsulting.com

[Jared Rypka-Hauer]

MG already has an SVN repository and that SVN repository has an
actionpacks section, so I really dislike the idea of creating yet
another (non-) authoritative container for MG-related stuffages.

That is to say: If we're going to do this let's put a bit of planning
into it and not start scattering stuff around. :)

J

[Chris Blackwell]

Jared, i think your are right here, we don't need yet another location for resources.

An official MG repository on the model-glue.com domain would be ideal.  Searchable, and indexable by the search engines (which i doubt the svn repo is)

I know that Ray Camden has previously made the riaforge source available for others to use, would that not be a good starting point for a MG repo... ?  It is a MG3 app IIRC.

Chris

2009/10/27 Jared Rypka-Hauer <armcha...@gmail.com>

[todd sharp]

riaforge is MG2

--
Todd Sharp
Sharp Interactive, LLC
http://slidesix.com -- Multimedia Enabled Presentation Sharing
IM:  cfsi...@gmail.com
Blog:  http://cfsilence.com
Twitter: cfsilence | slidesix

[Chris Blackwell]

I coulda sworn Ray posted about event-types and riaforge.. i must of dreamt it.

doubt it would be much work to update to MG3.  

2009/10/27 todd sharp <to...@cfsilence.com>

[todd sharp]

maybe he did - i could be wrong

[Dennis Clark]

On Tue, Oct 27, 2009 at 11:34 AM, Jared Rypka-Hauer <armcha...@gmail.com> wrote:

MG already has an SVN repository and that SVN repository has an
actionpacks section, so I really dislike the idea of creating yet
another (non-) authoritative container for MG-related stuffages.

SVN mostly works for the centralized management of the core code for MG, but I feel that actionpack development should follow a more decentralized model, and SVN is a poor fit here. I feel that what we really need at this point is to encourage participation and the sharing of ideas on actionpack coding, and Git makes this very easy (once you learn how to get started with Git, that is).

For example, if there were a actionpack GitHub repository, Bob could clone it to write his fileupload actionpack. When his actionpack is ready he could offer it to the master; let's say it was accepted. If I then clone the master and get some ideas to improve Bob's actionpack, I could offer a patch to Bob instead of to the master. If Bob likes my patch, he could merge all or part of it into his clone. Bob and I could continue to exchange patches between our clones this way until Bob becomes satisfied with the improvements, at which point he would offer a new update of his actionpack to the master. Such collaborative development is extremely difficult to pull off in SVN.

(The above is based on my current understanding of Git: if you know Git to work differently, please correct me).

Contrast this with the MG core. I've been working on some changes to the MG core codebase. I have a bit more work to do on it so I'm not ready to offer any patches. I'm not a member of the official MG team so I don't have SVN commit rights and therefore cannot use the official repository to track my changes (not that I really want to). This leaves me with 3 choices:

1. Leave my changes untracked and perform regular svn updates to keep my copy current with the official trunk (easy).

2. Create my own personal SVN repository and perform an svn import/merge every time I want to pull in official trunk updates (painful).

3. Create a personal Git repository that overlaps my working copy of the official SVN repository (confusing?).

In any case, the only other repository I can really follow with SVN is upstream. This is OK for the MG core code because the upstream code has higher status than my code (or any other outside fork for that matter). It is my job to keep up with upstream if I want my patches to ever be accepted, but it is not upstream's job to keep up with any of my patches. If I want to share my patches with another person, my patches would always have to be against an official branch. This makes it difficult for developers that are not part of the official MG team to collaborate on core code changes that vary significantly from the official base; however this is usually in the best interest of the core project.

I find it quite acceptable to have both an actionpacks section in the official SVN repository as well as a less-official actionpacks GitHub repository. We would certainly want to make it clear that the GitHub actionpacks are all works-in-progress and people who want official stable actionpacks should look in the official MG project site instead. The official MG team would of course promote whichever actionpacks they like in GitHub to their SVN repository (as long as the code licensing is compatible).

My idea is to create a single RIAForge project for community-developed MG actionpacks, and have the RIAForge project include a link to a GitHub repository that hosts the source. The project would therefore not be any harder to find than any other RIAForge project. RIAForge projects can use any source control they like (including no source control at all); the use of svn.riaforge.org is not mandatory. Zips of the GitHub repository contents should be regularly posted to the RIAForge project for those who'd rather not mess with Git.

Just a thought...

Cheers,

-- Dennis

[denstar]

This is sort of a tangent, but...

I think Mark Drew was working on an MG3 "dashboard" type of deal...

I've been going nuts with Railo's extension stuff (easy way to install code)...

Maybe we could do something similar with the dashboard? Just point it
at location X to get a list of actionpacks, pick one, and then fire
off some type of install process?

That way we're not locking wanna-be actionpack coders into the actual
MG release cycle deal... plus, being concerned about what code you put
on your box isn't a bad thing... er--

I'd typed this up before Dennis sent his git stuff, so um, yeah.

--
Our first intuitions are the true ones.
Emile M. Cioran

[Dennis Clark]

I also thought about the issue of installing actionpacks from a potentially large collection, but didn't say anything because I didn't have any real suggestions for it at the time.

To me actionpacks feel more like modules than projects, which tends to make me think of my experience with Perl Package Manager (PPM). Rather than having to find a Perl module I need, download it manually, and install it, I can use PPM to do it for me using a command like 'ppm install somePackage'. Of course there are plenty of other systems like this these days; a package manager becomes essential whenever the number of available packages becomes large.

If this MG3 dashboard that denstar mentioned could offer a similar package management feature for actionpacks, it could help users pick-and-choose from actionpacks available across multiple individual projects. Collaboration between different actionpack coders would become less important. It'd be perfectly fine to have 5 different file upload actionpacks or 15 different user management actionpacks; just pick the ones you like the most!

 

Anyone know what the status is of this alleged dashboard? Does it exist, and if it does exist is there any plans to include package management features?

-- Dennis

[denstar]

On Tue, Oct 27, 2009 at 3:11 PM, Dennis Clark wrote:
...

> Anyone know what the status is of this alleged dashboard? Does it exist, and
> if it does exist is there any plans to include package management features?

I sent MD a message, asking for the code he'd done, as I was going to
make something similar to a dashboard for my super-duper code
generation stuff.

--
Reason is a whore, surviving by simulation, versatility, and shamelessness.
Emile M. Cioran

[Gareth Cole]

Hi,

 

I was wondering if the code for this was ever implemented into MG?

 

I had developed something similar about a year ago for a MG2 application. I had a generic controller function that would handle uploading and validating files. From this discussion, it seems that putting it inside a service may have made more sense.

 

While it worked ok for simple files, things got complicated when uploading images. For example, certain images would require to be stored in 3 different sizes. Others would need their corners rounded. I got it to work by adding extra controller functions, but that didn't feel right at all - the image processing should be within the model.

 

I'd be interested to hear how other people do this?

In particular, I like the sound of File System Objects that encapsulate the file handling. Are there any blog posts/sample code for these, or are they easy enough to build?

 

Thanks,

 

Gareth

 

 

 

From: model...@googlegroups.com [mailto:model...@googlegroups.com] On Behalf Of Bob Silverberg
Sent: 16 October 2009 15:47
To: model...@googlegroups.com
Cc: John Whish
Subject: [Model-Glue] Who should upload files?

 

I was just having an interesting conversation with John Whish about where we think file uploads should occur in an OO application.  We are both processing our file uploads using a Filesystem object (FSO), which we both agree should be responsible for doing the actual uploads, and simply returning data about the upload to the caller (e.g., success, filename, etc).

We are also both currently call that FSO from a Service.  We were discussing whether to move that logic into the Business Objects (BOs) themselves.  I tend to try to keep my services dumb, and to push logic into the BOs whenever possible, so this seemed like a candidate, but then we discussed the fact that the BO shouldn't need to know that a file upload has to occur at all.  Maybe one day the file won't be uploaded, maybe it will come from another source altogether. So we decided that the BO shouldn't know about the file upload, and therefore shouldn't be responsible for asking the FSO to do the upload, so that brings us back to the service.

But then we discussed the fact that the file upload isn't really a model concern at all.  That the model should be independent of the client that's calling it. So really the service shouldn't need to know that a file has to be uploaded either. So that leaves the controller.  Again, we try to keep our controllers reasonably dumb and lean, so although this seemed to be the place to do it in theory, we didn't like the idea of having to add a bunch of code into each controller method that involved a file upload.

So, by now you're probably wondering, why the heck is he writing this to the Model-Glue group. Well, we figured that the job of uploading files really belongs in the controller, and the controller is an extension of the MVC framework, so maybe this really should be the job of the MVC framework.  The implementation that we imagine would involve convention, and would basically be something along the lines of:

1. Framework receives request.
2. Framework takes input data (i.e., form and url scope) and puts them into event object.
3. Framework looks for files to be uploaded - could be done via a convention on naming of form fields (or maybe it's possible to look at the content of a form field to determine if it contains a file?)
4. Framework attempts to upload said files and places metadata about the uploads (e.g., success, filename, etc) into the event object
5. Framework then passes control to the controller for the event, which now has access to all of the data, and the files are already uploaded.

Of course this isn't a simple matter.  What happens, for example, if one of the uploads fails?  Also, it might be nice if this could somehow be a separate component that could be injected into the request lifecycle, rather than adding it to the core of the framework itself.

So this discussion raises a few questions for John and I:

1. Is it possible to do something like this without touching the core files of MG?  Is there a plugin point for something like this?
2. Is this even a good idea at all?  What thoughts do people have about where this upload should occur?
3. If it is a good idea, what ideas do people have about how to implement it?  Currently our thinking is to base it on convention, so it would happen automatically.

Thanks for taking the time to read this, and thanks for any thoughts you may have.  Perhaps I'll see some of you tonight/tomorrow in Raleigh.

Cheers,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

--~--~---------~--~----~------------~-------~--~----~
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog

You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
-~----------~----~----~----~------~----~------~--~---