> Mosh Teitelbaum wrote:
> >OK, so let me flip this around a bit (no pun intended): In your
experience,
> >how often do you have one developer working on the form and another
working
> >on the action file? Or, more generically, how often do you have
developers
> >working on individual files instead of groups of files collectively
(i.e.,
> >all of the files needed to add an item to the shopping cart)?
Brian Kotek wrote:
> On a small project this might not happen very often. But as a
> project gets bigger, or especially as changes are made to
> existing code, the benefits get bigger and bigger.
But even in larger projects, changes made to one file will necessarily
require changes in other files. For example, if you add a new field to a
form, the action page needs to be updated to validate/initialize/etc. this
new value, the DB for adding and editing need to be modified to support this
new value, etc.
I'd never consider having multiple developers tackle a problem like this.
I'd rather issue a single CR ("add field X to form Y") and assign it to a
single developer who then has to modify all associated files. This aids in
development time (think synchronization), unit testing,
documentation/commenting, etc.
> >Granted, for maintenance purposes, this might happen frequently, but in
most
> >of those cases, the issue being resolved is a code error and not a
> >redirection update. And in the cases of redirections, the person making
the
> >fix would have to know where to redirect the request, making the whole
> >"doesn't need to know anything" point moot.
>
> This isn't quite correct...the developer making changes to the
> code still needs to know nothing about the redirect target. That
> change is made to the XFA variable by the architect. In fact, if
> the only thing changing is the redirect, you don't even have to
> open the code file. Just edit the circuit.xml file (in Fusebox
> 4) and change the target of the XFA.
This doesn't really address my point. If the change is one of redirection,
whoever is responsible for making the change (developer to a code file *or*
architect to a circuit file) has to know the target of the redirection.
> >On a similar note, I much prefer that my developers know the internals of
a
> >system instead of working blind. Not so much that they can make changes
but
> >rather so that they can understand the reason why things work out the way
> >they do.
>
> Again, for a small system this might be feasable. But for large
> applications with hundreds of files, dozens of directories and
> thousands of lines of code, there is simply no way for all of the
> developers to know and understand all the internals of the
> system. Because Fusebox handles each small piece separately from
> the others (fuses don't know about how they are called or what
> happens after they are called, logical and physical structure are
> separate, control logic isolated in circuit.xml file, etc.) it
> handles large applications very nicely.
OK, so let me clarify my earlier statement: I'd much rather my developers
know the internals of the file on which they are working and all related
files be they part of a module, application, what have you. I'd love it if
all of my developers would learn every aspect of every part of the site.
But there's no time or need for that. However, there is a very real need
for developers to know about the file they are working on (which you agree
with) and all related files (which I'm not sure if you agree with).
As a real world example, a developer is working on a Shopping Cart system.
His responsibility is to code the functionality that lets a user add an item
to the cart. The documentation tells him that he can expect certain input
data and must output certain other data. IMO, this developer should be
building the form to find accept quantity data, the update price display,
the validation code, etc. This is because (a) the guy who wrote the form is
almost certainly the best prepared to write the code that accepts the form's
data and (b) he needs both the form, the validation, and the processing
pages to effectively unit test his code. Yes, I know about test harnesses,
etc. but I prefer seeing real world results in addition to outputting state.
> First, managing the circuit structure is incredibly easy, so it's
> not like this is a lot of extra work.
I would think this depends on the complexity and scope of the site, whether
or not you intend to nest circuits, etc.
> >1) I have to have logic in my form that, based on the object type,
displays
> >or hides the cascade checkbox. Personally, I don't have much of a
problem
> >with this example. But if we extend the example to include other
systems,
> >objects, etc. each with their own set of additional form controls, we
start
> >having problems.
>
> Not really. You'd set up different fuseactions to build
> different parts of the form, and call them only when you need
> them. If one part of the form is only used some of the time,
> it's only invoked and used in some of the fuseactions. Fusebox 4
> has the ability to call any number of fuseactions internally,
> with no performance penalty, and capture the resulting output
> into content components that can be used later to build a final
> display. This is incredibly powerful, and would easily solve the
> problem you specified in number 1).
No offense, but "ugh." I've been forced to work with forms that are built
piece-meal and I have always hated it and have rarely seen the benefit in
doing so. Also, this doesn't really answer my point. You're still
modifying the form dynamically based on the object type (or the specific
fuseaction) you're just doing so in a different file.
> >2) Like the additional logic in the display code, the action code also
has
> >to include IF/ELSE blocks that check the object type, etc.
>
> Nope...using XFA's you'd point to different fuseactions that
> handle the action code in their own way.
But then you're no longer reusing code, which is the most often stated
benefit of using XFAs.
> Or better yet, point to
> one fuseaction that handles the actions common to multiple uses
> of the form, then call other fuseactions specific to handling the
> current, specific use of the form.
I'm still kind of torn about this kind of a system. It can add all kinds of
design headaches when dealing with transactional control of data. It also
can lead to a change made for one action rippling to other actions with
negative effect.
> >3) This can get way out of hand when privileges differ from object type
to
> >object type. Also, if each object is stored in its own table (i.e., you
> >have separate FILE and DIRECTORY tables instead of a single DocLibObject
> >table) then the action code now needs to determine which DB query to call
> >(add to FILE or add to DIRECTORY)?
>
> Again, the dynamic nature of XFA's negates this percieved
> problem. At runtime, insert the proper XFA that points to the
> appropriate fuseaction and runs the appropriate query.
As before, you'd no longer be reusing code... benefit... XFAs.
> As an aside, would your solution to these problems be duplicating
> code in multiple forms and action files?
Sort of. Other than the few examples that I mentioned earlier on in the
thread, I don't believe that reuse of forms is a good thing only because
most forms are specific to the properties of the item that is being
added/edited. If every item only had a name and a description, then form
reuse would be easy and useful (IMO). But that's just not the case. And
as I said before, I'm very much against building forms widget-at-a-time.
> >Refactoring to optimize performance, add new functionality (fuseaction)
to
> >an existing feature (circuit), or adding a whole new feature (circuit)
are
> >common but usually do not require renaming of directories and/or files.
> >Splitting a circuit seems to me like there was a problem with the
original
> >design of the system.
>
> They don't always require renaming of files or directories, but
> it's great to know that when it does, the change is painless.
But given the downsides I've mentioned (perceived or otherwise), is this a
common enough occurrence to put up with the downsides?
> And as crazy as it sounds, no architect, whoever they may be,
> will always design the perfect system up front. There will
> ALWAYS be problems with the original design of the system,
> because in the real world, things change. Being able to make
> changes quickly while isolating the effect of those changes is a
> huge plus...and did I mention Fusebox helps greatly with this?
I realize that not everyone can architect a system as perfectly as I can
<smirk> but most well designed architectures can easily adapt to changes in
the requirements. That's why, even though I tend to bill my clients for
roughly 30% design time and 70% development time, the actual work is usually
closer to the opposite.
> >> No problem Mosh, and no swipes or attacks are percieved. I love
> >> the chance to talk about Fusebox and understand things about it
> >> that people don't like or don't understand completely. Thanks for
> >> your views.
> >
> >Likewise 8^).
>
> I wonder how long we can do this before our heads start hurting. ;-)
Bleh, it already hurts. I leave for 3 hours and this thread turns into an
abstraction of a flame war 8^).
--
Mosh Teitelbaum
evoch, LLC
Tel: (301) 942-5378
Fax: (301) 933-3651
Email: [EMAIL PROTECTED]
WWW: http://www.evoch.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community.
http://www.fusionauthority.com/ads.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
