Well, there really isn't away to make CVS ignore some suset of files within a
given repository....
However, it has been our experience that it isn't really workable to have
non-developers mucking with the HTML templates and WOD files on a regular
basis. Sure-- occasionally adjusting a template is one thing, but as soon as
it moves to setting up templates and declarations files, then it becomes a
software development issue and the creative production folks are not generally
equipped to deal with that.
A lot of it has to do with mindset.
Most of the folks in Creative will have come from some kind of a content
production or editorial background. That is, they are used to a publishing
cycle and not a development cycle. In a publishing cycle, it is common to
adjust layouts and content up until the final proof. As well, the concept of
PAGE is very strong while the concept of reusable componets across pages is
weak.
This holds true of web content production, as well-- most content production
folk think in terms of pages. While there may be common elements across pages,
it is not uncommon to find that those elements have been tweaked here and there
to make 'em fit better into the page's content. Because HTML was not
originally designed as a look-n-feel page description language, a lot of the
content will be tweaked on a per-page basis to make it look good across all
browsers.
Unfortunately, this "page centric" production cycle is counter to an
application development cycle.
In application development, one typically takes a functionality centric
approach to development. Typically, the application is broken into functional
units and those units are refined until there are two piles; reusable,
somewhat general purpose objects, that implement the functionality of the
application and a set of highly specific objects that implement the details of
the application through the use of the reusable objects.
This means that items like a search tool, nav bars, common information displays
and the like will be naturally componentized in the functionality centric
approach to development. However, in a page centric view, two pages that have
a functionally identical search tool may have very different HTML describing
the UI of the search tool.
IN other words, simply providing a development environment that allows the
creative department to diddle the HTML and WOD files while the developers are
diddling the back end isn't necessarily the answer. You need to make very
careful sure that the creative folk understand that they are dealing with an
application development process and you need to make the developers aware that
the UI may be structured in a fashion that is not intuitive to one steeped in
OO design and construction.
With WebObjects 4.0, there are a myriad of different ways to address this
disparity.
We [CodeFab] have quite successfully integrated purely static HTML with
WebObjects code through the liberal use of direct actions and other
mechanisms. This has allowed the creative folks to "take ownership" of certain
pieces of UI that are relatively fluid within our clients' sites-- the creative
folks then have the freedom to keep up with the marketing folk by spinning
whatever HTML they fill is necessary to implement a particular piece of content
or feature.
We have yet to run into a situation where we could give the creative folk
creative license to do what they want to the HTML/WOD within the applications
without basically giving the creative folks a fairly serious education about
application development and componentized, reusable, user interface
construction. This isn't to say that it isn't possible-- we just haven't seen
it happen yet.
(I am, by no means, slighting the ability or value of those in the creative
department. Like application development, user interface construction--
especially for the WWW-- is a difficult science. Creating good user interfaces
is an intense combination of art and science. It is just like software
development in that to do it well takes lots of experience, thought and skill--
we structure projects such that the Creative resources can do what they do best
while the developers do what they do best. When it is possible to overlap the
two, we do so-- but we don't set up projects such that either side is directly
responsible for the other's deliverables (beyond both sides having to meet
their own schedules on time so as to not delay the other)).
b.bum
Patrick Gallagher wrote:
> Hello!
>
> At my current client, there is a separate Creative Dept. that handles the
> HTML generation. We would like to set up CVS to support both Development
> and Creative, but in such a way that Creative only gets the files they
> need (html and wod) when they check out their module.
>
> Perhaps the ideal solution would be to "lay the modules on top of each
> other in the repository. So, when Development checks out the DEV module,
> they get source, html, wods, the whole deal. When Creative checks out
> the HTML module, they get the same html and wods as the developers, but
> nothing more. Basically, the HTML module would be a subset of the DEV
> module. Can this be done with CVS?
>
> What techniques are people using to address this type of division of
> responsibilities?
>
> TIA!
>
> PG
>
> --
> ---------------------------------------------------------------------------
> Patrick Gallagher <[EMAIL PROTECTED]>
> (NeXTmail and MIME welcome)
> ---------------------------------------------------------------------------
> "There is more to life than increasing its speed."
> -Mohandas Karamchand Gandhi (1869-1948)
> ---------------------------------------------------------------------------
