Re: [Gusdev-gusdev] Struts documentation - supporting evidence

[Steve F. <sfi...@pc...>]

ok, sounds good on both points.

steve

Adrian Roy Tivey wrote:

>>Adrian-
>>
>>i am only going to address one point now, pending more time to review 
>>and learn.  that said, on the whole, this looks very good.
>>
>>i would like to address, point (1), the build system and the directory 
>>structure.  your answer below says "the dir struct is self contained, 
>>and we're using ant, so no prob."   i am not quite sure if you mean (a) 
>>that therefore we can use the dir struct you have with the build sys, or 
>>(b) it would be easy to rearrange it to conform.  if case (a), i'm not 
>>sure i see compatibility here: the dir struct has many of the same 
>>elements of those that we use in GUS, but, they are arranged 
>>differently.   i should mention that i do think it would be very easy to 
>>stuff this kind of thing into our dir struct, but, since i don't have a 
>>thorough comprehension yet, perhaps not.
>>    
>>
>
>I think (b). We deliberately tried to limit the number of dependancies in the
>demo so didn't try and integrate it into the GUS build mechanism, which I
>haven't got in front of me. I would guess the src and lib directories (any
>others?) should be merged into the existing dir. structure. The rest is really
>website specific so should probably go into a new (file-system) branch, wdk or
>something. Does this sound reasonable?  
>
>
>  
>
>>a subpoint of that point:  you say below that you envision overlaying 
>>files to acheive customization.  I think i want to hear more about 
>>that.  my concern is that overlaying violates good subclassing 
>>practice.  in particular, if i overlay code, then i have to duplicate 
>>the "base" code in my customized version that i still want.
>>    
>>
>
>Although the docs. didn't make it clear we're not really thinking about
>overlaying the code. As you say there are already mechanisms for reusing it
>while still extending and/or modifying its behaviour (either by inheritance or
>delegation). But there are no similar mechanisms for images, layouts, JSP pages,
>query config files etc. So it's those that people can override by overlay. (One
>slight extension - if we have an XInclude processor we can potentially split the
>various XML config files into sections so that other sites can include shared
>sections they want without cut'n'pasting.)
>
>  
>
>>steve
>>    
>>
>
>A
>  
>