Stefano Mazzocchi said in reply to Peter Hunsberger (recursively for many days now...)
>> No problem, I'm somewhat amazed that you have found the time to follow >> up at all... > > Like I said in the past, I like healthy and friendly discussions > expecially with people that disagrees with my views, because that's how > I normally learn things. Fair enough :-) I've also found over the years that just the process of trying to explain things to people helps me understand them better; I wasn't completely sure what I was looking for when I jumped in on this thread. I'm still not sure that I know completely what I want, but I'm a lot closer. >> 1) I hadn't really made the differentiation between your semantics and >> mine partly because the term "callPage" implies, to me, a "call" to a >> named resource. As such, it seems to me that the command to jump out >> of the flow layer should be something more like "applyURI" or >> "resolveURI"; you're not calling a named resource, your resolving a >> URI in your flow? > > the methods are called 'sendPage*', Peter. We are not calling anything. > We are handling control to the resource production logic which is > contained inside the sitemap. Whoops, my bad. I guess it was just all the examples I had seen that seemed to refer to a simple named resource and not a URI. However, "send" also seems bad; sort of like "goto" from the evil pre-structured programming days... Also, isn't it possible (though possibly rare) that nothing ever gets sent and that the invoked resource just does some back end processing and then the flow should carry on? For example, on the E-commerce site I had a interface to the credit card processor (that I invoked as a black box), essentially an external data validation process that it would have been good to encapsulate as separate part of the flow. > applyURI and resolveURI don't make any sense to me in this context, > because you are not applying a URI (you are asking for the sitemap to > generate that resource) and you are not resolving a URI (resolving, in > my book, means mapping from one URI to another URI) Well the point is, when you dump a URI into the sitemap you may not know exactly what resources are going to be matched up against it; thus the sitemap "resolves" the mapping of the URI to the resource. However, I think I like the suggestions towards more receiver like semantics, like "getUserInput()" or similar. Though that seems to leave the non-waiting version a little orphaned? Maybe it's a combination of both: "getUserInput()" and "applyResources()" for the waiting and non-waiting calls respectively? Certainly "page" seems wrong, since page oriented media are not the norm on the web? <snip on rest of agreement/> >> For example, in the past I built an e-commerce site for the rental of >> charter jets. The process of chartering a jet has many steps, 4 of >> which could be done in any order, and the last two of which (credit >> card validation and final confirmation) had to be done in a specific >> order. If I had URIs like: >> >> xxx/charter?step=n >> xxx/cardvalidate >> xxx/finalconfirm >> >> then I don't expect there'd be much guessing on the "contract"? > > well, my father (who doesn't know english) wouldn't agree :) Not sure any mapping will help in that case... > but the point is not about 'guessing' the contract, is about *having* > it. It could even be made of a list of numeric pages IDs (that might be > very handy for you, I don't know and I don't care, it's your choice) or > they could well be chinese URIs. As long as there is a solid contract, > there is separation and that's what I care for. Yes, I agree. My point was that the contract is pretty explicit either way. >>>This enforces separation. Might be painful at first, but *very* useful >>>down the road when you can manage and maintain your flow without having >>>to touch (or being afraid others touch!) the resource-producing >>>pipelines and the URI space (which acts as a contract between the flow >>>and the sitemap, enforcing good use of internal contracts and parallel >>>development between separate teams) >> >> Well, like I said I can see why you want that contract. The added >> abstraction does provide some useful separation. The same separation >> can be maintained by using explicitly named resource; > > Well, you are, in fact, explicitly naming a resource with a URI. I don't see that; if it's a URI how you do you know what resource will be matched up against it by the sitemap? Isn't the fact that you don't always explicitly know the mapping part of your rational for using a URI and not a name? >> but why introduce another mapping between the two layers? >> The only reason I can see might be for >> performance; you can enforce name uniqueness in the sitemap and then >> hash directly to the resource from the name saving the URI resolution >> step. For cases where you want to really use a URI then you support >> that also, thus you may want both "resolveURI" and "callResource"; one >> which processes a general URI and the other which allows Cocoon to >> shortcut directly to the resource as composed in the sitemap. > > I see your point, but I don't know why we should make another layer of > indirection... performance aside, do you envision a functional reason > for having that? I thought you where proposing the indirection by using a URI as opposed to a uniquely named resource? In either case, I can possibly see a reason for the indirection: if you want to include other external systems in the flow then you can only do it by having a mapping layer that parcels out the calls as needed. In that manner, the flow manager becomes a modular system where Cocoon is perhaps just part of the picture and you have a way of plugging in other (non-Cocoon) resources. I would maybe support having a syntax that allowed for that as a future possibility (pseudo protocols seem to fit the bill) but I can't see that you want to otherwise bite off on that for any immediate future release...? <snip on more agreement/> >>>I would call for 'inefficiency' right there. You are basically sending >>>thru *all* your metadata even if you don't know you're going to use it >>>or not. >> >> Well no, I'm still using multiple pipelines to aggregate different >> metadata sources as they are needed for a given resource. So, not >> everything gets processed every time. However, the complexity of our >> business rules does require us to process a lot more metadata than >> other people would ever think rational... > > Still I don't buy how a 'push model' (I'll send you what you think > you're going to need) can be more efficient than a 'pull model' (you ask > me what you want), but that might well be me. The main reason for such a strategy is that back end calls can be expensive and given the rules based nature of our system you can't tell what resources are required until the rules are processed (eg; you don't know that past history is needed until you discover that the user is doing a search on a patient who hasn't given the protocol a disclosure agreement). As such, it's much cheaper to grab all the metadata and most of the data in a single back end query than it is to do in multiple passes. This is in fact one of the big problems we ran into with the old system. We have, for example, a patient questionnaire that currently makes 19 separate trips up and down through the EJB structure just to build the object model and 19 more trips to assemble the data. With the new system we do it all in a single trip. This might seem like a lot of metadata and data but on average it doesn't work out that way. There are exceptions, and we have a special object type for the cases where it makes more sense to make a second pass. <snip on more agreement/> Thanks for your time once more... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
