On 12/03/09 2:08 AM, "Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
> David Hunter wrote:
>> D.1 option is more what I was thinking but either way I think keeping the
>> backend away from the rxml coders and administration access from tags would
>> allow the backend to change without effecting the rxml using them.
>
> I'm not sure I understand what you mean here. What could be changing and
> in what ways could this unduly influence the RXML programmers?
Ok. Selecting what database to store the info would do the job here I think
Under std operation this would be in the roxen database but I need the
ability to use an external db setup in roxen.
I was mainly indicating that generally there should be no need to write
queries into the back end as below.
>> How a user implements administration is then upto the user how they use the
>> tags. Maybe the ability to add them in the interface as well.
>
> Does it really need this much administration?
> I'd guess that 99% of all users are perfectly fine with a default
> configuration
> calling up /cron.rxml?hour=14 every hour (specifying which hour it is).
> Then they decide inside the cron.rxml what (not) to do at that time.
Im dealing with up to 40 individual files and have client ability to
configure these within there site. But ability to add/update in the module
interface as well as tags available to add/update and display would cover
that.
>> Currently the module I have has configuaration options that supply some site
>> specific variables to the rxml being parsed so would probably want some
>> method of specifying variables to be made available to the rxml being parsed
>> that is more generic and not hardcoded into the module.
>
> Variables other than the current date/time? Could you give some examples of
> what you pass now?
Just any variables we want to make available to all the scripts. One example
is the folder that scripts output 'OUTFILE' or load data 'LOAD DATA' to and
from mysql need to suit the server environment. We have several machines
that just use /tmp/ for this but others that use an NFS share to a remote
machine. Even a box to input std rxml would suit and have that parsed first
in the same context.
>> As I see it if there was a tag to update or add a new entry. That would
>> trigger that module to reload its entries as well as at boot time.
>
> You'd be wrapping SQL, seems to me that the level of complexity saved
> is rather small, so it might not be worth the trouble to provide the wrappers.
We need to be able to administer the entries from the website and I would
rather have error handling etc in the module.
>> I suspect using the roxen database would be a good way to store & retrieve
>> the information but maybe storing also it in a static configuration would
>> allow for site migrations better.
>
> Well, make it flexible and allow storage in the Roxen database as well as
> in an external database of choice.
Agree as above.
Dave.
|