[Mono-list] A Plugin and WebService Issue

[Pablo Fischer]

--=-DdajjwNYuuKzX14zBXPk
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Sure,

I'd like to be sure that the plugin of the user has a 'Post' method for
example, or a 'DeletePost', if all the 'rules' are ok the code will be
compiled with an AssemblyInfo.

I know that I can verify if the method exists invoking it and if I get
Null there's no method, but I'd like to do this also in the compilation
process.

See ya!
El s=E1b, 22-05-2004 a las 00:22, Rob.Tillie@Student.tUL.EDU escribi=F3:
> Could you tell us why you want to check the code?
>=20
> Greetz,
> -- Rob.
>=20
> -----Original Message-----
> From: Pablo Fischer [mailto:pablo@pablo.com.mx]=20
> Sent: Thursday, May 20, 2004 5:04 PM
> To: mono-list@lists.ximian.com
> Subject: Re: [Mono-list] A Plugin and WebService Issue
>=20
> Thanks people!
>=20
> When I start writing my app (mbloggy) I was using Interfaces as plugins
> (xmlrpc plugins), then I started reading info about SOAP and I'm in love
> with it, the fact that SOAP supports any encoding makes me happy :-).
>=20
> What I was looking for is to do the same that "Plugins in Mono" (M.
> Icaza) says :-).
>=20
> However, I'd like to ask something else: I want EVERY plugin be compiled
> like I want, yeah, when I compile the plugin (the .dll) I'd like to
> check the methods and validate the plugin, if the plugin is ok, compile
> it and add some Assembly Info (AssemblyInfo, right?), where should I
> look?, NUnit I think is to check compiled applications but I want to
> 'check' my code BEFORE being a .dll.
>=20
> Thanks!
> Pablo
> El jue, 20-05-2004 a las 05:38, RoBiK escribi=F3:
> > Hi,
> >=20
> > I would use this approach:
> >=20
> > 1) you must have a plug-in Interface defined, that each plug-in must
> > implement
> > 2) when the application starts, use static System.IO.Directory.GetFiles=
()
> > method to get the names of assemblies in the plug-in directory
> > 3) for each plug-in-assembly file call static
> > System.Reflection.Assembly.LoadFrom() method to load the assembly into =
the
> > current AppDomain, then call the method
> > System.Reflection.Assembly.GetTypes() on the System.Reflection.Assembly
> > instance that you've got from the previous LoadFrom() method
> > 4) for each Type that you get from previous GetType() method use the "i=
s"
> > operator to check if the particular type implements the plug-in interfa=
ce,
> > if it does, you have a type that implements your plug-in interface.=20
> > 5) call static Syste.Activator.CreateInstance() method with the type fr=
om
> > previous step as parameter. Cast the result to the plug-in-interface ty=
pe
> > and store it for example in an array for later use.
> > 6) now you have an array of plug-in instances and can call the interfac=
e
> > methods on them
> >=20
> > This is just an example, there are several other approaches which are m=
ore
> > or less similar to this one... everything depends on the needs of your
> > application.
> >=20
> > RoBiK
> >=20
> > Quoting Pablo Fischer <pablo@pablo.com.mx>:
> >=20
> > > Hi!
> > >
> > > I would like to have some comments and suggestions about a issue.
> > >
> > > I am working in a Blog Client (mbloggy) that will work ONLY in SOAP (=
NO
> > > XMLRPC) for different CMS and Blogs (phpnuke, postnuke, jaws, etc, et=
c).
> > > To work with all these blogs I'm  planning to use a 'plugin' system,
> > > based in assemblies, for example:
> > >
> > > If a developer wants the plugin for a CMS (like drupal), he can save =
his
> > > .dll plugin in ~./mbloggy/plugins and when mbloggy starts it will rea=
d
> > > default plugins (in /etc/mbloggy) and the user plugins. When mbloggy
> > > finds a new plugin it will be added to a 'drop down' (gtk#) so the us=
er
> > > can use it.
> > >
> > > My problem?, yes, I don't know which is the best option:
> > >
> > > a) Use .dll assemblies as plugins. But, how to connect to each plugin
> > > from the front end?, exists a data type that can 'clone' another
> > > object?, so I can do something like this:
> > >
> > > Wrapper wrap =3D new Wrapper();
> > > wrap.Clone("assemblie.dll");
> > > wrap.Url =3D "http://www.foo.bar.com/foo.aspx?wsdl"
> > > wrap.DeletePost(3);
> > >
> > > So I can use the 'methods' of assemblie.dll in the wrap object?.
> > >
> > > b) Or use just one .dll and let the developers to 'develop' just the
> > > WebService (server)?, So I can just work like this:
> > >
> > > Client c =3D new Client();
> > > c.Url =3D "http://www.foo.bar.com/foo.aspx?wsdl"
> > > c.DeletePost(3);
> > >
> > > Which is the best option? and where can I find more information for t=
he
> > > best option?.
> > >
> > > Thanks!
> > > Pablo
> > > --
> > > Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
> > > Fingerprint:  5973 0F10 543F 54AE 1E41  EC81 0840 A10A 74A4 E5C0
> > > http://www.pablo.com.mx
> > > http://www.debianmexico.org
> > >
--=20
Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
Fingerprint:  5973 0F10 543F 54AE 1E41  EC81 0840 A10A 74A4 E5C0
http://www.pablo.com.mx=20
http://www.debianmexico.org

--=-DdajjwNYuuKzX14zBXPk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAr3kLCEChCnSk5cARAogZAJsEnEJFelB4xNVw6H6GAuh+Ayv80gCfQCUF
Oc4iSztLJOs4uua51/9KkFg=
=wkug
-----END PGP SIGNATURE-----

--=-DdajjwNYuuKzX14zBXPk--