[Lazarus] WebData

[Michael Van Canneyt]

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.