CODERS PLEASE DISCUSS!!! Pre-Datastore modifications with XML-files (UPDATE 28-7)

[Marco van Herwaarden]

Second Alternative presented.

This one uses a table that gets merged during loading of the datastore rows.
Data is released inside the regular Product XML file that you use for your hack.

See newly attached file for details.

Again, please comment!!!!

[merk]

Con's in this alternative:
- Will also execute if Plugin System is globally disabled (chicken and egg problem, or extra queries needed)
- A lot more file modifications needed
- Script to maintain the information stored in the table not written (yet?).
Should anyway only be available in debug mode?
- Need to create a new table
- Query to use when loading the datastore on each page load might be slowed down considerably. This should be tested
in a representable environment. Same goes for alternative 1.
- This alternative only handles new datastore items, not template caching like alternative 1

If the plugin system is disabled, it could set a flag in the system (somehow) to also not load the extra datastore items, though it probably wont work because vboptions is in the datastore.

Not having looked at your proof of concept, I would have thought the only file modification needed would be in the datastore class to modify the query. It shouldnt be necessary on each pageload to do anything else..

I dont see creating another table as an issue - the more tables you have to deal with things the better! - I also dont believe that a query joined to this table would be slower than reading an XML file from the filesystem.

Template caching can already be achieved with a hook..?

[deathemperor]

Originally Posted by KirbyDE

Global and Action Templates can already be added through Plugins

Sorry if this goes off topic, but can you share your way to code this ?

[Marco van Herwaarden]

Originally Posted by merk

If the plugin system is disabled, it could set a flag in the system (somehow) to also not load the extra datastore items, though it probably wont work because vboptions is in the datastore.

I don't think that would chang a lot, since it would have to be stored somehow, it would also have to be retrieved, resulting in an extra query. (Not that an extra well designed query should always be such a big issue).

Originally Posted by merk

Not having looked at your proof of concept, I would have thought the only file modification needed would be in the datastore class to modify the query. It shouldnt be necessary on each pageload to do anything else..

To implement it, only 1 modification to the datastore class is made. Ofcourse this added code must be executed on each pageload, how you would want to retrieve the info otherwise?

The other modifications are management code (loading the table with the product XML-File, disabling the entry when the product is disabled, etc.)

Originally Posted by merk

I dont see creating another table as an issue - the more tables you have to deal with things the better! - I also dont believe that a query joined to this table would be slower than reading an XML file from the filesystem.

Creating another table is not an issue if Jelsoft is doing it, it is something to consider when a Third Party (us) is making changes to the database design.

Originally Posted by merk

Template caching can already be achieved with a hook..?

I am taking the word of others on this, not tried it myself, but this was the beauty of Alternative 1 in my eyes. We could ofcourse always create something similar to the datastore hack for this. (Could be stored in datastore, so no extra query would be needed.)

[Andreas]

Originally Posted by deathemperor

Sorry if this goes off topic, but can you share your way to code this ?

Hook cache_templates

[Andreas]

Originally Posted by MarcoH64

Con's in this alternative:
- Will also execute if Plugin System is globally disabled (chicken and egg problem, or extra queries needed)

Uhh, yes - that is a Problem. Hmm, thinking about that.

- A lot more file modifications needed

Haven't really implemented it yet, but in theory it should be just a few lines in init.php?

- This alternative only handles new datastore items, not template caching like alternative 1

Idea: Seriaized DS Entry that holds Phrase/Template Requirements for every Script. This entry would have to be loaded always, the currently required Data extracted and merged with $phraseggroups etc.

[Marco van Herwaarden]

Originally Posted by KirbyDE

Haven't really implemented it yet, but in theory it should be just a few lines in init.php?

Already answered by:

Originally Posted by MarcoH64

To implement it, only 1 modification to the datastore class is made. Ofcourse this added code must be executed on each pageload, how you would want to retrieve the info otherwise?

The other modifications are management code (loading the table with the product XML-File, disabling the entry when the product is disabled, etc.)

Quote:

Originally Posted by KirbyDE

Idea: Seriaized DS Entry that holds Phrase/Template Requirements for every Script. This entry would have to be loaded always, the currently required Data extracted and merged with $phraseggroups etc.

Since our primary focus was on datastore and templates/phrases can already be done by plugins, this is not coded into Alternative 2. In alternative 1, i was able to easily catch all 4 arrays, within the same structure and edit location.

To implement phrases/templates into Alt. 2, completly different code would be needed compaired with the datastore solution (because the problem is different - adding things prior to having the datastore available - versus - adding things after we have the datastore). What they do have in common is that we could use the same table to store the info, with some slight modifications. I even started with columns in the table to support this, but i removed them later since i didn't plan to implement it.

PS We are being watched by Jelsoft on the progress in this thread (i think ) and there might be a very slight chance that Jelsoft might adopt an idea (which would be the best solution for the community i think).

[Marco van Herwaarden]

I am a bit disappointed at the lack of feedback and discussion in this thread from most coders.

[Paul M]

Originally Posted by MarcoH64

I am a bit disappointed at the lack of feedback and discussion in this thread from most coders.

Probably because having read it, I'm somewhat confused as to what the original problem is/was and what exactly you are trying to achieve. Perhaps I'll have another read after my holiday.

(and unrelated - but long thread titles with tons of CAPITALS in them are ones I tend to avoid ....)

[Revan]

So let me see if I understood this correctly - you want to be able to add new phrasegroups/actiontemplates to existing vB pages?

My suggestion:

AdminCP:
New file: Import/Export/Editing/Deletion of an XML file record containing list of templates/phrases required for each mod. A dupe of the plugin system, so to speak, only it contains a possiblity to amend to every single instance of the $xxxtemplates arrays, including subarrays.
Every time something is added/edited/removed from this list, a flatfile (similar to the flatfile DS cache option in vB) is created. Obviously it does array searches to make sure no duplicates are present (although they wouldn't do much harm).

Init.php:
Find

PHP Code:

require_once(CWD . '/includes/class_core.php'); 


Add below

PHP Code:

require_once(CWD . '/includes/datastore_precache.php'); 


From there, different parts of init.php can use variables from this file (again, similar to the datastore_cache.php) to do whatever it is you want it to do, such as array_merge($precache_templates, $specialtemplates); etc.


A simple require_once() won't bring any huge load onto the server, it won't be parsing anything and it won't be querying anything.