cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Sun, 31 Aug 2003 06:27:21 GMT
Stefano Mazzocchi wrote:

>
> On Saturday, Aug 23, 2003, at 15:41 Europe/Rome, Gianugo Rabellino wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino 
>>> wrote:
>>>
>>>> Looks like I missed some serious fun during these vacations... time 
>>>> to catch up!
>>>>
>>>> Stefano Mazzocchi wrote:
>>>>
>>>>>  Virtual Pipeline Components
>>>>>  ---------------------------
>>>>
>>>>
>>>>
>>>> Love the idea. Even because it was me suggesting something like 
>>>> that a couple of years ago and being blamed of FS... ;-)
>>>
>>> Really? any pointer? (I'm not being sarcastic, but curious... if I 
>>> judged FS something that I later ended up proposing, there is 
>>> something wrong in my FS meter ;-)
>>
>>
>> Sorry, no pointers, just witnesses if they remind the live discussion 
>> who took place one day in Bibop.:-) We were still using the compiled 
>> sitemap and I was suggesting how components could have been 
>> aggregated (G-T* / T* /T*-S) as "macros" to be unrolled by XSLT. You 
>> came up with FS bells and problems with parameter resolving, so the 
>> discussion was kinda over.
>
>
> ahhhhh, yeah, rings a bell... I remember that I thought about 
> fragmented resources and it was that that triggered my FS alarm. I 
> always knew that views were virtual serializers, but the specific 
> semantics was introduced to make it easier to understand (views are 
> heard enough to understand already).
>
> But anyway, no excuse, I was probably wrong at that time not to 
> consider this further. Or, maybe not: we needed more time to see if it 
> really made sense to add that complexity.
>
>> I will be more stubborn next time. ;-)
>
>
> Please do :-)
>
>>>>>  Pluggable Request Factories
>>>>>  ---------------------------
>>>>
>>>> 2. Are you sure that adapting the request is enough?
>>>
>>> I couldn't come up with anything that required more than that.
>>>
>>>> I'd say that the different use cases you're pointing out require a 
>>>> bit more then just the request object: I'd say that the whole 
>>>> environment might need a particular treatment in most cases.
>>>
>>> Why so, can you elaborate? maybe with a specific example? scenarios 
>>> help the design.
>>
>>
>> You might need to have access to the response too. In WebDAV world, 
>> as an example, you need to set a whole bunch of headers (Allow:, 
>> DAV:, MS-Author-Via - yuck - and more), and a DASL component needs to 
>> specify the search vocabularies supported. True, you can do it by 
>> hand, but it would be much better if such manipulation could be done 
>> by a "request-factory".
>
>
> Damn, great point.
>
> So, back one step: could "adapt-environment" help? or is "environment" 
> not good enough for people to understand?
>
> What do others think? 


Mmmh... Up to now, the environment is mostly non visible to regular 
components (i.e. out of the sitemap/pipeline machinery). Exposing it may 
lead to many abuses and misuses.

I would go back only a half-step : "adapt-object-model" sounds better as 
it provides all that it needed for Gianugo's use cases, and avoids 
messing up the environment.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message