Post by straightlight » Thu Nov 01, 2012 4:26 am

I added a statement to my post above.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 4:43 am

Edit: One aspect I did encountered is that preRender uses the same template buffer name whether it comes from the same or different author. It would be great to have an override system for template files as well.
You can always use something like this:

Code: Select all

<?php 
class myaddon_ControllerCatalogProduct extends ControllerCatalogProduct {

	// override method
	protected function preRender( $templateBuffer ) {
		// we are only interested in modifying the catalog/product_form.tpl
		if ($this->template != 'catalog/product_form.tpl') {
			return parent::preRender( $templateBuffer );
		}

		// do our template modifications,
		// or we can also add here some more variables into the 
		// $this->data, as needed by the modified template
		// ......

		// return the modified template
		return parent::preRender($templateBuffer);
	}
}
?>

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 4:50 am

As far as I understand, the same TPL files will be targeted which can create conflicts in fact the same that is already encountered in VQMod by modifying lines. How about creating cached template files by: 'myaddon_' as a starting prefix for each TPL files distributions which of course the: 'myaddon_' would be the real subject name distributed by each authors ?

For instance, this was already done for languages from your engine package (without prefix which could still rely on a starting prefix as well). I'm pretty sure it can also be done for templates when using the overrides. If the TPL file doesn't exist, then to simply create it and to dump the buffer into the cached template file. If the cached TPL file already exists, like VQMod does, simply to replace the content but this time by relying on the starting prefix name. ;)

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 5:12 am

straightlight wrote:As far as I understand, the same TPL files will be targeted which can create conflicts in fact the same that is already encountered in VQMod by modifying lines. How about creating cached template files by: 'myaddon_' as a starting prefix for each TPL files distributions which of course the: 'myaddon_' would be the real subject name distributed by each authors ?

For instance, this was already done for languages from your engine package. I'm pretty sure it can also be done for templates when using the overrides. If the TPL file doesn't exist, then to simply create it and to dump the buffer into the cached template file. ;)
So how would this solve the problem when multiple addons try to modify the same template? How exactly should the addons template changes be merged?

A typical frontend web theme uses its own directory, e.g. catalog/view/theme/mytheme, and if a template needs to modified by the new web theme (because it's beyond merely modifying the CSS), then it should be copied from the default web theme to the new one.

For example, let's say the header.tpl needs changes for the new theme. It would be copied to the new web theme:
catalog/view/theme/mytheme/template/common/header.tpl
And all the needed modifications would be in there, hardcoded, specific to the requirements of the new web theme. If the new web theme happen to need new variables, these could be set in an overridden preRender method, located for instance at override/mytheme/catalog/controller/common/header.php.

It is quite rare having to modify templates by overriden preRender calls, except for some general addons.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 5:26 am

A typical frontend web theme uses its own directory, e.g. catalog/view/theme/mytheme, and if a template needs to modified by the new web theme (because it's beyond merely modifying the CSS), then it should be copied from the default web theme to the new one.
The replication should not only be based by folders but also by file names that represent those folders and also when initialed from the preRender method which the current folder name should also be implied based on the $this->config->get or from the already existing DIR_TEMPLATE path in the render() method.

For instance,

instead of:

Code: Select all

preRender( $templateBuffer )
we would have:

Code: Select all

preRender( 'myaddon', $templateBuffer )
Then, from your modified controller engine file, inside the preRender method, the starting prefix name with the buffer variable could be linked in order to create a cached template file.

Then, an instanced variable could get this starting prefix in order to be used in your render() method below when a file whether doesn't exist and have to create or when it already exists in order to replace it with the appropriate folder name and the same for languages.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 5:38 am

You are basically talking about caching the template, using file names that includes the name of the addon, the name of the web theme, and the name of the template.

However, the question remains: How to exactly merge template changes carried out by multiple addons to the same template. I do not yet have an elegant solution for this.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 5:41 am

However, the question remains: How to exactly merge template changes carried out by multiple addons to the same template. I do not yet have an elegant solution for this.
By using a starting prefix name for each file names based on distributions as it should of been the same for XML files within VQMod for relying on the author's name with from its constructor by using: $modObject->author . '_' . $this->_cacheName($stripped_filename) from the $stripped_filename variable or similar inside the foreach loop (which in your case would rather be the while loop statement instead) from the render() method.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 6:15 am

By using a starting prefix name for each file names based on distributions as it should of been the same for XML files within VQMod for relying on the author's name with from its constructor by using: $modObject->author . '_' . $this->_cacheName($stripped_filename) from the $stripped_filename variable or similar inside the foreach loop (which in your case would rather be the while loop statement instead) from the render() method.
You lost me here.

Lets give an example:

addon1 needs to modify catalog/view/theme/mytheme/template/common/header.tpl.
addon2 also needs to modify catalog/view/theme/mytheme/template/common/header.tpl.

How exactly are the changes from addon1 and addon2 to be merged into a final template for the rendering?

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 6:23 am

How exactly are the changes from addon1 and addon2 to be merged into a final template for the rendering?
Simple.
Addon1: catalog/view/theme/mytheme/template/common/header.tpl.
Addon2: catalog/view/theme/mytheme/template/common/header.tpl.
to read:

Code: Select all

catalog/view/theme/mytheme/template/common/myaddon_header.tpl.
catalog/view/theme/mytheme/template/common/mysecondaddon_header.tpl.
A little similitude on what should of had been with VQMod but hasn't been which caused millions of users in conflict otherwise than:

Code: Select all

<author>
in each XML files ? Then:
vqmod/vqcache/vq2-author_xpath_header.tpl
which the author should be set to strtolower and trim by also replacing all unwanted characters from the file name that excludes: a-zA-Z0-9_

Code: Select all

preg_replace('/[^a-zA-Z0-9_]/is', '', strtolower(trim($var))))
which $var would be for this example. Once all the previous statement is cleaned out, to include the DIR_TEMPLATE along with the file (so, in this case, mytheme) which is already predefined originally in OpenCart. Otherwise, people wouldn't be able to render templates from the controller anyhow.

Of course, if the above replacement is empty, then clearly the <author> tag is improperly described in order to fit in a cached template file. ;)

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 6:39 am

You still haven't answered the crucial question:

How exactly are the changes from addon1 and addon2 to be merged into a final template for the rendering? addon1 is not aware of addon2, as each one of them was created by a different author. And the controller expects one final template, in whatever manner it got generated from all the addon changes, to be rendered.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 6:52 am

you still haven't answered the crucial question
Beg to differ. I already did.
the controller expects one final template, in whatever manner it got generated from all the addon changes, to be rendered.
While this statement is correct, the whole point is to modify the controller's template routine to load each templates by authors rather than one final template and the same for controller, language and model files.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 7:12 am

Beg to differ. I already did.
No, you didn't. It's one thing to load several author's templates, where each author has done its own minor changes compared the original one. But the controller wants only one final merged template to be rendered.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 7:15 am

But the controller wants only one final merged template to be rendered.
Yet again the why it has to be by authors rather than one final merged template to be rendered. Otherwise, your engine will be at the same end as VQMod.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Thu Nov 01, 2012 7:26 am

straightlight wrote: Yet again the why it has to be by authors rather than one final merged template to be rendered. Otherwise, your engine will be at the same end as VQMod.
So are you saying that, if 10 different authors want to modify the same header.tpl for their addons, only one author gets the chance to be used for the final rendering, and the other authors' changes are to be discarded?

So

author1_addon-name_catalog_view_theme_web-theme_template_common_header.tpl

gets the winning ticket for the final rendering by the controller, while

author2_addon-name_catalog_view_theme_web-theme_template_common_header.tpl
...
author10_addon-name_catalog_view_theme_web-theme_template_common_header.tpl

are all discarded?

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Thu Nov 01, 2012 7:55 am

So are you saying that, if 10 different authors want to modify the same header.tpl for their addons, only one author gets the chance to be used for the final rendering, and the other authors' changes are to be discarded?
No, ok. What I'm saying is that right now, VQMod already does regroup each XML files with their lines into the vqcache folder outputted in PHP files. Although, the reason why this conflict exists and shouldn't exist is because there's only one final controller and does NOT cached files by distributions since no matter the mount of distributions that are involved, if two contributors or more decides to modify the same file and around the same lines or straight on the same lines (even though it is only justified by x that it is only by specific lines from the line that conflicts would be involved), your engine will just reproduce the same behavior as VQMod since the results are still ending with one final files of each subjects - controller, language, model and template files.

Instead, what should be done and even simpler to understand the concept, is since XML files are distributed by authors, then the vqcache files must also be distributed by authors to avoid the conflicts ? Logically, it really sounds right to me as the same as it should rather be with your modified engine; no restrictions for other authors, same access to all but OpenCart would still have to load the controller, language, model and template files by authors name.
author1_addon-name_catalog_view_theme_web-theme_template_common_header.tpl

gets the winning ticket for the final rendering by the controller, while

author2_addon-name_catalog_view_theme_web-theme_template_common_header.tpl
...
author10_addon-name_catalog_view_theme_web-theme_template_common_header.tpl
It should rather be more like this:
catalog_view_theme_web-theme_template_common_author_addon-name_header.tpl
See, the path detection doesn't really change. Only the final point of each folders between the file extension and the last slash from the folders.

Additionally, by using the x for the author, it would be dangerous distinction since multiple author x could exist by coincidence on the entire planet as only the first author of the used author x statement from the <author> tag would be able to use its contribution from the cache or the other way around, the first author would loose its contribution from the cache by being overwritten by the 2nd author containing the same author x name which would be even worst. Although, if the time() would be involved in the vqcache folder and the same for the engine and that <generatedContributionTime> tag would exist in the XML for VQMod or for your case the $this->generatedContributionTime instance variable would exist amongst the modified engine, it would be way more easy to distinguish and to trace the conflict between two same authors name.

What if the generatedContributionTime is generated at the same time on both end ?

Two possibilities:

- It's the same guy who wants to test your product and just want to see the results for tricking the controller.
- It's two different people that knows each other and has an understanding between them to generate the micro time period at the same time, still, to trick the controller.

- It's another author who did a save as and didn't figured out to change the micro time period which caused a conflict with the original time period of the original distribution.

- It's two different people that really has generated the time manually by coincidence and they don't know each other (which I would really doubt). If it's the case though, then I would really be damned about it since not even a payment gateway / offline payment processing would be able to reproduce this systematically when a customer completes an order since engineers has already thought of this solution a long time ago. How could this be possible on files ? Still, if this possibility happens particularly, it would really be between two different authors and knowing where exactly the conflicts might come from.
catalog_view_theme_web-theme_template_common_authorx_addon-name_header.tpl
Now, rather than using an x on the author, an additional tag for VQMod or for your case from the modified engine with something like this:

VQMod:

Code: Select all

<modifiedTimeSalt>12werjk345rtnmk</modifiedTimeSalt>
and for your modified engine:

Code: Select all

$this->modifiedTimeSalt = '';
and when the contributor codes from its addon controller file:

Code: Select all

$this->modifiedTimeSalt = '12werjk345rtnmk';
which the author has to generate as a unique string per each new distributions and being used amongst the target cache file name along with the authors name and the rest of the long path as demonstrated above. If not used as a generic file name for the string (since we're talking about regrouping the data like VQMod but by Authors), then to keep its track from string knowing if there are possible duplicate entries of the string. Understandably, a salted string should be generated longer than that on screen but since this is about file name, we do have to limit the string's length a little bit. This way, it would not even be harden to create a conflict but in fact almost impossible to create one on one and another. If the named tags or instanced variable, for both cases independently of course, doesn't exist or has found two matches from two different authors or above, then these people needs to revise on each ends so to avoid conflicting on one and another until these strings are loaded as a unique string for each regroup cached files.
are all discarded?
Not discarded; regrouped. The same way as VQMod already does right now except by author's name as a prefix as demonstrated above.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by zaycho » Fri Nov 02, 2012 12:22 am

JNeuhoff wrote:

Code: Select all

<?php
class myaddon_ModelAccountCustomer extends ModelAccountCustomer {

	public function addCustomer($data) {
		parent::addCustomer($data);

		// also add the newfield to the customer record
		$sql  = "UPDATE `".DB_PREFIX."customer` SET newfield = '".$data['newfield']."' ";
		$sql .= "WHERE email = '".$data['email']."'";
		$this->db->query( $sql );
	}
}
....
?>
This means also two database call instead of one. Am I correct? Is there a way to avoid this? For example if I am the only developer and want just to replace core function with my own one.

New member

Posts

Joined
Thu May 12, 2011 4:02 am

Post by JNeuhoff » Fri Nov 02, 2012 12:32 am

zaycho wrote: This means also two database call instead of one. Am I correct? Is there a way to avoid this? For example if I am the only developer and want just to replace core function with my own one.
While there is indeed an additional DB query, I don't think it has an impact on the performance to worry about.

In theory you could avoid calling the parent method in your overridden method as long as there are no other addons overriding the same method. A bit dangerous though because some time in the future you might install another 3rd party addon which happen to override exactly the same core method.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by JNeuhoff » Fri Nov 02, 2012 12:47 am

straightlight wrote:
are all discarded?
Not discarded; regrouped. The same way as VQMod already does right now except by author's name as a prefix as demonstrated above.
Why don't you write up a solution and release it under a GPL license?

Frankly, I still don't see how your approach allows multiple addons from different authors to modify the same core template, or simpler, the same core method. Adding salted time stamps and author names for cached file names doesn't do it. But prove me wrong, write up something to demonstrate what you have in mind, and then lets see.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by straightlight » Fri Nov 02, 2012 5:54 am

Frankly, I still don't see how your approach allows multiple addons from different authors to modify the same core template, or simpler, the same core method.
If you believe my brief statement above is about modifying the same core template or the same core method, then you are clearly missing the point. Hopefully, someone will read this and understand it eventually to have a solid override system since this is what is really needed for OpenCart as well for contributors.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Fri Nov 02, 2012 6:04 pm

straightlight wrote:
Frankly, I still don't see how your approach allows multiple addons from different authors to modify the same core template, or simpler, the same core method.
If you believe my brief statement above is about modifying the same core template or the same core method, then you are clearly missing the point. Hopefully, someone will read this and understand it eventually to have a solid override system since this is what is really needed for OpenCart as well for contributors.
This override engine has the capability for several independent addons to modify the same core method or template. You are welcome to write up a better core engine, or to improve this one. It's all released under the GPL.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am

Who is online

Users browsing this forum: No registered users and 23 guests