View fields not working correctly after more fields and more conditional JavaScript were added #203

Closed
opened 2017-12-21 08:59:52 +00:00 by stutteringp0et · 15 comments
stutteringp0et commented 2017-12-21 08:59:52 +00:00 (Migrated from github.com)

Steps to reproduce the issue

  1. Site Views Javascript tab - textarea always enabled
  2. Site Views PHP - radios and textareas all mixed up.
    Ajax opens nothing,
    custom document script opens nothing,
    custom view script opens jview legacy display,
    custom JViewLegacy display opens a textarea below custom JViewLegacy methods
    custom JViewLegacy methods opens custom document script

Expected result

less wierdness

Actual result

wierdness

System information (as much as possible)

Additional comments

### Steps to reproduce the issue 1. Site Views Javascript tab - textarea always enabled 2. Site Views PHP - radios and textareas all mixed up. Ajax opens nothing, custom document script opens nothing, custom view script opens jview legacy display, custom JViewLegacy display opens a textarea below custom JViewLegacy methods custom JViewLegacy methods opens custom document script ### Expected result less wierdness ### Actual result wierdness ### System information (as much as possible) ### Additional comments

Please review issue 202

You will basically need to clear your browser history, since it still loads the old JavaScript.

Please review [issue 202](https://github.com/vdm-io/Joomla-Component-Builder/issues/202) You will basically need to clear your browser history, since it still loads the old JavaScript.

But hey there is your field to add the JavaScript to a file 👍 instead of the document method.

I have had this issue many times, where I add new fields to a page and also new JavaScript to control the field behavior. But then other will have to clear their browser history before things work. Not sure what I can do to prevent that from happening.

But hey there is your field to add the JavaScript to a file :+1: instead of the document method. I have had this issue many times, where I add new fields to a page and also new JavaScript to control the field behavior. But then other will have to clear their browser history before things work. Not sure what I can do to prevent that from happening.

Any ideas?

Any ideas?
stutteringp0et commented 2017-12-21 12:37:00 +00:00 (Migrated from github.com)

Yes, $doc->addScriptVersion() should fix that permanently.

Yes, $doc->addScriptVersion() should fix that permanently.

Hmmm it says

The method is deprecated, use addScript(url, attributes, options) instead.

So we can add the attributes and options right in the addScript method. Okay that much I can understand, but how to do the versioning automatically via JCB...

What we have now, is it adds a file, here is an example.

First in the model:

/**
 * Method to get the script that have to be included on the form
 *
 * @return string	script files
 */
public function getScript()
{
	return 'administrator/components/com_componentbuilder/models/forms/admin_view.js';
}

Then in the view on two places, first:

$this->script = $this->get('Script');

Second:

$this->document->addScript(JURI::root() . $this->script);

These are the areas that must be fixed

That means we need to on line 200 in the view do something like this:

$this->document->addScript(JURI::root() . $this->script, $options, $attribs);

With signature we have the following:

  • $options Array of options. Example: array('version' => 'auto', 'conditional' => 'lt IE 9')
  • $attribs Array of attributes. Example: array('id' => 'scriptid', 'async' => 'async', 'data-test' => 1)

The trick is to know those values dynamically.

Any ideas? We have a file version in the compiler, but it is not always used by the developer as it is controlled by this switch in the Joomla-Component area:
image
You will see one of the option is:
image

When a user has it set to that option, the compiler can actually add a view version number, that only changes if the view was updated in JCB.

So I think to add this version number in here.

Can you give me some more explanation on all the other details and what you think we should add in as values, using the admin_view as our example.

Hmmm it says >The method is deprecated, use addScript(url, attributes, options) instead. So we can add the attributes and options right in the addScript method. Okay that much I can understand, but how to do the versioning automatically via JCB... What we have now, is it adds a file, here is an example. First in [the model](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/models/admin_view.php#L506): ``` /** * Method to get the script that have to be included on the form * * @return string script files */ public function getScript() { return 'administrator/components/com_componentbuilder/models/forms/admin_view.js'; } ``` Then in the view on two places, [first](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/views/admin_view/view.html.php#L46): ``` $this->script = $this->get('Script'); ``` [Second](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/views/admin_view/view.html.php#L200): ``` $this->document->addScript(JURI::root() . $this->script); ``` ### These are the areas that must be fixed That means we need to on [line 200](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/views/admin_view/view.html.php#L200) in the view do something like this: ``` $this->document->addScript(JURI::root() . $this->script, $options, $attribs); ``` With signature we have the following: - $options Array of options. Example: array('version' => 'auto', 'conditional' => 'lt IE 9') - $attribs Array of attributes. Example: array('id' => 'scriptid', 'async' => 'async', 'data-test' => 1) > The trick is to know those values dynamically. Any ideas? We have a file version in the compiler, but it is not always used by the developer as it is controlled by this switch in the Joomla-Component area: ![image](https://user-images.githubusercontent.com/5607939/34276903-24f90678-e6ac-11e7-9b7d-ca966497265b.png) You will see one of the option is: ![image](https://user-images.githubusercontent.com/5607939/34276923-426f5a04-e6ac-11e7-9002-4463b91def04.png) When a user has it set to that option, the compiler can actually add a view version number, that only changes if the view was updated in JCB. So I think to add this version number in here. Can you give me some more explanation on all the other details and what you think we should add in as values, using the admin_view as our example.
stutteringp0et commented 2017-12-22 00:28:41 +00:00 (Migrated from github.com)

addScriptVersion is deprecated? They just added it in 3.2!

Digging deeper......They didn't remove the functionality - they just deprecated a helper method. Joomla still does it, you just have to initiate it in $options.

OK... addScript grabs the version number from.....the $options input....which if null or 'auto' in $this->_scripts[$url]['options']['version'] is autopopulated.

So, $doc->addScript('path/to/script.js',array('version'=>'auto')) should do it.

From there the renderer picks up the version from $document->getMediaVersion().....and I'm not sure where that comes from - but I just tested and this works. I think they take a sum of the installed extension manifests or something. The number is stable until I update an extension (any extension), then it changes.

I say rely on Joomla to handle it. It's how they got past the "clear your cache" instruction between Joomla updates...which, as I recall was around 3.2...

addScriptVersion is deprecated? They just added it in 3.2! Digging deeper......They didn't remove the functionality - they just deprecated a helper method. Joomla still does it, you just have to initiate it in $options. OK... addScript grabs the version number from.....the $options input....which if null or 'auto' in $this->_scripts[$url]['options']['version'] is autopopulated. So, $doc->addScript('path/to/script.js',array('version'=>'auto')) should do it. From there the renderer picks up the version from $document->getMediaVersion().....and I'm not sure where that comes from - but I just tested and this works. I think they take a sum of the installed extension manifests or something. The number is stable until I update an extension (any extension), then it changes. I say rely on Joomla to handle it. It's how they got past the "clear your cache" instruction between Joomla updates...which, as I recall was around 3.2...
stutteringp0et commented 2017-12-22 00:31:05 +00:00 (Migrated from github.com)

Additional test - the same thing works for addStyleSheet. adding a 'version'='auto' option causes Joomla to add a version sum to CSS links as well.

Additional test - the same thing works for addStyleSheet. adding a 'version'='auto' option causes Joomla to add a version sum to CSS links as well.

So far it looks like the version is build by the version class, I am still searching. So when the documents is created in the Factory class:

/**
 * Create a document object
 *
 * @return  \JDocument object
 *
 * @see     \JDocument
 * @since   11.1
 */
protected static function createDocument()
{
	$lang = self::getLanguage();

	$input = self::getApplication()->input;
	$type = $input->get('format', 'html', 'cmd');

	$version = new Version;

	$attributes = array(
		'charset'      => 'utf-8',
		'lineend'      => 'unix',
		'tab'          => "\t",
		'language'     => $lang->getTag(),
		'direction'    => $lang->isRtl() ? 'rtl' : 'ltr',
		/*  OVER HERE */
		'mediaversion' => $version->getMediaVersion(),
	);

	return \JDocument::getInstance($type, $attributes);
}

That does mean the update will be linked to the date and will reload the file basically every time, look here is the generateMediaVersion method that is used in getMediaVersion to build the version hash.

/**
 * Generate a media version string for assets
 * Public to allow third party developers to use it
 *
 * @return  string
 *
 * @since   3.2
 */
public function generateMediaVersion()
{
	$date = new \JDate;

	return md5($this->getLongVersion() . \JFactory::getConfig()->get('secret') . $date->toSql());
}

This is not good.

So far it looks like the version is build by the version class, I am still searching. So when the documents is created in the Factory class: ``` /** * Create a document object * * @return \JDocument object * * @see \JDocument * @since 11.1 */ protected static function createDocument() { $lang = self::getLanguage(); $input = self::getApplication()->input; $type = $input->get('format', 'html', 'cmd'); $version = new Version; $attributes = array( 'charset' => 'utf-8', 'lineend' => 'unix', 'tab' => "\t", 'language' => $lang->getTag(), 'direction' => $lang->isRtl() ? 'rtl' : 'ltr', /* OVER HERE */ 'mediaversion' => $version->getMediaVersion(), ); return \JDocument::getInstance($type, $attributes); } ``` That does mean the update will be linked to the date and will reload the file basically every time, look here is the [generateMediaVersion method](https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Version.php#L295) that is used in [getMediaVersion](https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Version.php#L313) to build the version hash. ``` /** * Generate a media version string for assets * Public to allow third party developers to use it * * @return string * * @since 3.2 */ public function generateMediaVersion() { $date = new \JDate; return md5($this->getLongVersion() . \JFactory::getConfig()->get('secret') . $date->toSql()); } ``` This is not good.

I think we should build our own version generator in the model, and so insure the file only updates if it changes. Should not be to hard, we can use some of their ideas, infact we can even try to use the Version class.

I think we should build our own version generator in the model, and so insure the file only updates if it changes. Should not be to hard, we can use some of their ideas, infact we can even try to use the Version class.

Okay so here it is actually explained.

/**
 * Gets a media version which is used to append to Joomla core media files.
 *
 * This media version is used to append to Joomla core media in order to trick browsers into
 * reloading the CSS and JavaScript, because they think the files are renewed.
 * The media version is renewed after Joomla core update, install, discover_install and uninstallation.
 *
 * @return  string  The media version.
 *
 * @since   3.2
 */

The media version is renewed after Joomla core update, install, discover_install and uninstallation.

Hmmm am I missing something here? or does that mean only if the core is changed does that string change.

Okay so here it is actually explained. ``` /** * Gets a media version which is used to append to Joomla core media files. * * This media version is used to append to Joomla core media in order to trick browsers into * reloading the CSS and JavaScript, because they think the files are renewed. * The media version is renewed after Joomla core update, install, discover_install and uninstallation. * * @return string The media version. * * @since 3.2 */ ``` ### The media version is renewed after Joomla core update, install, discover_install and uninstallation. Hmmm am I missing something here? or does that mean only if the core is changed does that string change.

Okay so I still think we should do our own versioning but use some of their tricks to make it easy.

Okay so I still think we should do our own versioning but use some of their tricks to make it easy.
stutteringp0et commented 2017-12-22 13:33:01 +00:00 (Migrated from github.com)

I read that as any install operation....that covers all that I can think of. Discover installs occur when you build an extension in place and then ask joomla to discover it.

I read that as any install operation....that covers all that I can think of. Discover installs occur when you build an extension in place and then ask joomla to discover it.

So any component being installed resets it?

So any component being installed resets it?

Are you sure? let me take a look in the component manager.

Are you sure? let me take a look in the component manager.

Okay this is the command used to reset the string

JFactory::getApplication()->flushAssets();

and it is used in the Installer class, so you are right. Okay then it is fine, we can use auto 👍

Okay this is the command used to reset the string ``` JFactory::getApplication()->flushAssets(); ``` and it is used in the Installer class, so you are right. Okay then it is fine, we can use auto :+1:
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: joomla/Component-Builder#203
No description provided.