On Fri, 15 Oct 2010, Leonardo M. Ramé wrote:

On 2010-10-15 15:06:12 +0200, Michael Van Canneyt wrote:



Well, It's not an issue at all, I could create a stored procedure in
charge of receiveing the params from the dataprovider, then adapt them to
their respective tables. It's not an issue because I usually work with
Firebird and PostgreSql, and they have stored procedures.

I ask this because I'm thinking of adding a new layer of abstraction by
letting the TFPWebProviderDataModule load a configuration from, say, an
XML file with the list of Providers and its Select, Insert, Update, and
Delete statements, like this:

Aha !! I have this on my todo list as well :-)

Only I wasn't going to use XML, but .INI format.
In fact the file format is irrelevant; I planned to do it in 2 levels:

TFileWebDataProvider
 +- TIniFileWebdataProvider

I was going to put it in a separate component, but make the
TFPWebProviderDataModule aware of this component. Gives more
options.

Michael.

I attached a proof of concept, take a look and comment.

Seems like a very good start, some suggestions:

1. You created something which is by definition non-visual ?
   Why not make the TDynamicSQLWebProvider a component which you can drop on a 
webmodule ?

2. Having done 1, you could rework TModuleProvider so it recognizes and uses a 
TDynamicSQLWebProvider dropped on it.
   (if I understand correctly, there is no need to do anything, it would be 
automatic if the
    TDynamicSQLWebProvider uses it's owner as the owner for the providers)

3. Why not create the providers on an as-needed basis ?
   Now you create all registered providers.
   If you override the GetProvider method in TModuleProvider, you can simply 
create the instance you actually need.

   My projects contain typically 1000+ providers.
   If I would create them all in memory per connection - memory consumption 
would rocket sky high :-)

   I would simply load the definitions - once - and then create providers on an 
as-needed basis.

4. You forgot the XMLprovider unit :-)
   Seems like you make it a procedural interface to load the definitions.
   I would expect that TSqlWebDataProviders has a virtual abstract method which 
loads the definitions from file:
   Procedure LoadFromFile(Const AFileName : String); virtual; Abstract;
   In the case of a component, there could even be a 'FileName' property, read 
in the 'Loaded' method.
   then create a descendent which loads from whatever file format is fitting.

5. Advanced concept:
   Why didn't you use the TFPWebDataProviderManager factory class ? (see demo5)

   It is built for this kind of thing. (I currently use that at work) : you 
register all providers there.
   TFPWebProviderDataModule knows about this class and fetches a provider there 
on-demand.
   All you'd need to do is register 1 TModuleProvider instance there.  This is 
optional of course.
   So in fact, there are 2 paths you could follow.

I hope all this makes sense :-)

Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to