Design Patterns discussion

["Uwe Zdun" <uwe.zdun AT wu-wien.ac.at>]

Chris,

we had a paper at last Europlop addressing the issue of generic
parameter passing:

http://hillside.net/europlop/papers/WorkshopD/D3_PatowG%2B.pdf

also Alan Kelly's paper is related:

http://hillside.net/europlop/papers/WorkshopD/D2_KellyA.rtf

--Uwe


> -----Ursprüngliche Nachricht-----
> Von: 
> gang-of-4-patterns-admin AT cs.uiuc.edu
> [mailto:gang-of-4-patterns-admin AT cs.uiuc.edu]Im
>  Auftrag von Chris
> Finlayson
> Gesendet: Donnerstag, 11. Dezember 2003 21:43
> An: 
> gang-of-4-patterns AT cs.uiuc.edu
> Betreff: [gang-of-4-patterns] general parameter passing patterns
>
>
> Hi everyone:
>
> I'm encountering a problem that must've been solved about a million times
> over, but I'm having the darndest time trying to find patterns addressing
> the problem specifically.  I bet the answer's right in front of
> my face, but
> I'm not looking.
>
> The best I've found is an implementation that more-or-less solves my needs
> in Java's JAI (java advanced imaging) api.
>
> Make-believe you have a stand alone windows application that you want to
> allow people to extend via an API.  Now this is a big problem,
> but I'm most
> curious on the specific aspect of supporting the definition and passing of
> parameters.  Here's a scenario:
>
> 1. A user defines some business logic that requires some parameters and
> hooks it into the application via the API.
> 2. The user writes the GUI portion to correspond to the business logic and
> hooks it into the application via the API.
>
> There are several issues desirable to address:
>
> 1. The parameters required by the customized plugin may be of
> varying types
> (ints, doubles, blah blah).
> 2. The parameters have associated with them a description and maybe some
> help text that the GUI will display.
> 3. Each custom plugin may have varying numbers of parameters
> 4. Plugins may evolve over time, causing its parameter requirements to
> change
> 5. Appropriate parameters should be "rememberred" and passed through other
> plugins where appropriate, so the user doesn't have to keep filling in
> redundant data.  I'll elaborate on this one slightly.  Maybe the
> customized
> plugin asks the user for a document in addition to some other stuff so it
> can do its magic.  Generally speaking, it may be desirable to
> pre-fill this
> document field with the most recent one the user was working with.  So the
> parameter mechanism needs some sort of registration/discovery technique
> like:
>
>               string sDocumentPath =
> ParameterRegistry.getParamValue("DOCUMENT");
>
> Object broker paradigms such as COM sort of address these issues, but not
> entirely (admittedly I don't know that much about COM or related
> technologies).  I don't think COM addresses (5) and certainly not
> (2) in its
> methodology of dispatching params associated with an method invokation.
>
> Java's JAI seems to hit the nail on the head with its ParameterBlock,
> ParameterList, and ParameterListDescriptor classes/interfaces.  So, in a
> sense I have found my solution, but I would like to know of pointers to:
>       a) papers that address these issues from a patterns perspective
>       b) any implementation details people know of in C++.  I've looked at
> libraries in Boost and LOKI, but none seem to specifically encapsulate all
> these issues.
>
> Thanks!
>
> Chris.
>
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
>