Am 22.04.2014 18:10, schrieb Eddie Epstein: > The current design supports passing a specific view to an annotator: > map the desired view to the default view and do not declare the > annotator view aware by declaring input or output sofas. > > An alternate, unambiguous design would be that the default view > should always be delivered to the process method. Is this a better > model for you?
I actually solved the problem without changing any code. What I wanted, or what I would have expected, is that the CAS given in the process method is already the view mapped in the aggregate. The component that made the problems has a code fragment that checks the name of the given CAS and, if that is null, takes view with the default CAS (_InitialView). I actually don't remember why I added that. The aggregate maps now to that default view of the analysis engine instead of a specific one, and the analysis engine retrieves that view if the base CAS is given. So, no need for an additional parameter. That's all I wanted :-) Thanks Eddie, Peter > Eddie > > > > > On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl <[email protected]>wrote: > >> Am 18.04.2014 15:23, schrieb Eddie Epstein: >>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <[email protected] >>> wrote: >>> >>>> Am 17.04.2014 15:01, schrieb Eddie Epstein: >>>>> Hi Peter, >>>>> >>>>> The logic is that since a sofa aware component may have one or >>>>> more input and/or output views, such a component needs to use >>>>> getView to specify which to use. >>>>> >>>>> For sofa aware delegates, sofa mapping enables the delegate to >>>>> hard wire input and/or output View names in annotator code (or >>>>> annotator config parameters) and then have the real View names >>>>> assigned via mapping in the aggregate. >>>> Is the real view name in the mapping important at all since the view get >>>> accessed by the implementation in the process() method? >>>> >>> The real view name is what will be used when the CAS is serialized >>> to a file or to a remote service. >>> >> >> Yes, but that has nothing to do with the mapping, which is still obsolete. >> >> >>>> I don't see the effect of the mapping to the default input view of an >>>> sofa aware AE without input view capabilities at all. The mapping says >>>> view1 is linked, but another one arrives. >>>> >>> The input view for a sofa aware component is always the base CAS view, >>> for the reason given above. >>> >> I don't see the reasons. Why shouldn't the analysis engine get the view >> mapped in the aggregate? If the analysis engine has more input views, >> then it gets the base view and still can access them in the >> implementation. It actually has to anyway right now. If it has only one >> (or only the default view), then it can directly use the given one >> without a static implementation (getView("name")) or an additional >> parameter. I think this would enable the creation of better components >> and I actually have a use case right now. >> >> >>>> So, the best practice is to introduce a parameter for specifying the >>>> input view? In case that the AE implementation should be used several >>>> times in an AAE for different views. >>>> >>> Many if not most view aware components I've seen do not have a single >>> input view. >> >> Ruta has some, which do not work in pipelines when cascaded. >> >> Maybe I missed something, but I do not yet see any reasons why it should >> get the base view. >> >> Peter >> >> >>> Eddie >>> >>
