> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 26 April 2003 12:27
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: pgadmin3 wizard snapin technology
>
>
> There are a lot of ideas (many implemented in pgadmin2) to
> enhance pgadmin3 with wizards of all kinds, but currently we
> don't have a technology to easily snap in additional
> features. Suggestions? Do we need snapins anyway or should we
> simply link them into the main project?
Hi Andreas,
They are implemented as plugins to avoid the need for loads of extra
code that many people don't want, but recently, Frank made some *major*
changes to pga2 to give them more access to the pga internals -
something I'm not sure we could easily do in pga3.
To be honest though, I want to avoid getting tied up in auxilliary
functions of pgAdmin anyway. They can be high maintenance, and often
don't get used. How many people use the Publishing Wizard, or the
MSysConf wizard (or even the Upgrade Wizard which I must pull out of
pga3)?
The one exception is the Migration Wizard, which is probably the biggest
support drain there is because it's so easy to make it fall over (not
because it's no good, but because it has to interface with pretty much
anything which I often can't test). I've had a design for a new
Migration Wizard in mind since pga2 was written, though I never
implemented it (more like a non-nightmare version of Microsoft's DTS),
but it would be a major project in it's own right, and frankly I have no
real motivation for it anyway.
So, certainly for the first release of pga3, I don't want any plugins -
the only possible exception would be the Security Wizard - but I'd be
inclined to build that in anyway. As for Tom's suggestion, I'm thinking
we might build it in as an automated check. We can fairly easily tell if
there are more sets of constraint triggers in the system than there are
fkeys, so we could check at runtime and offer to fixup the catalogs.
Thoughts?
Regards, Dave.