Moving from PHPExcel to PhpSpreadsheet

Llewellyn commented

2019-07-16 22:30:12 +00:00

Owner

Steps to reproduce the issue

I think it is about time we move over to the new PHPSpreadsheet for import and export feature of JCB that gets auto added to all component.

Expected result

Complete new PhpSpreadsheet implementation in the helper classes

Actual result

We are 4years behind... 👎

Additional comments

I think we should do this in a more sync-able way to stay instep with the latest version of PhpSpreadsheet

### Steps to reproduce the issue I think it is about time we move over to the new [PHPSpreadsheet](https://github.com/PHPOffice/PhpSpreadsheet) for import and export feature of JCB that gets auto added to all component. ### Expected result Complete new PhpSpreadsheet implementation in the helper classes ### Actual result We are [4years behind](https://github.com/PHPOffice/PHPExcel)... :-1: ### Additional comments I think we should do this in a more sync-able way to stay instep with the latest version of PhpSpreadsheet

mwweb commented

2019-07-17 17:37:18 +00:00

(Migrated from github.com)

Author

Owner

Just a thought, but perhaps when it compiles it uses a library, kind of like for UIKIT 3?

Llewellyn commented

2019-07-17 19:26:24 +00:00

Author

Owner

Yes I was also thinking about those options... reality is that we have it as part of every component when import and export of data is required in a view. So it is sort of happening without being noticed. So I am thinking to have it as a library instead of part of the helper folder. So to be installed as a Joomla library and if not installed then all import export also does not work and show buttons.

Then the one down side of the current JCB library is that you can't change the location, it always endsup in the media folder, and for the PhpSpreadsheet that is not ideal.

Yes I was also thinking about those options... reality is that we have it as part of every component when import and export of data is required in a view. So it is sort of happening without being noticed. So I am thinking to have it as a library instead of part of the helper folder. So to be installed as a Joomla library and if not installed then all import export also does not work and show buttons. Then the one down side of the current JCB library is that you can't change the location, it always endsup in the media folder, and for the PhpSpreadsheet that is not ideal.

Llewellyn commented

2019-07-20 23:45:37 +00:00

Author

Owner

Okay first step I will just update the library and update the way it works in all components build with JCB that has import and export. Just so we get the new lib in place... and have the old removed.

We an at a later stage see how we can improve the library area to also handle these kind of libraries, even with automated adding as we have in this case.

Okay first step I will just update the library and update the way it works in all components build with JCB that has import and export. Just so we get the new lib in place... and have the old removed. We an at a later stage see how we can improve the library area to also handle these kind of libraries, even with automated adding as we have in this case.

marcodings commented

2019-07-24 10:35:03 +00:00

(Migrated from github.com)

Author

Owner

Please condider adding "composer" based functionality on a library basis an not on a per component installation resulting in duplication.

Yes i'm aware thats yet another step into the future ;) but lets keep this future in mind when adding 3rd party stuff now

Please condider adding "composer" based functionality on a library basis an not on a per component installation resulting in duplication. Yes i'm aware thats yet another step into the future ;) but lets keep this future in mind when adding 3rd party stuff now

marcodings commented

2019-07-24 10:59:01 +00:00

(Migrated from github.com)

Author

Owner

Oops.. guess i should have read more than the first post

TLWebdesign commented

2019-10-01 15:55:09 +00:00

(Migrated from github.com)

Author

Owner

i guess first think to do is for @Llewellynvdm to fork the phpspreadsheet as a joomla package? If i'm smart enough i'd like to contribute to changing existing code to phpspreadsheet. Have this page as a reference: https://phpspreadsheet.readthedocs.io/en/latest/topics/migration-from-PHPExcel/

Kind regards,
Tom

i guess first think to do is for @Llewellynvdm to fork the phpspreadsheet as a joomla package? If i'm smart enough i'd like to contribute to changing existing code to phpspreadsheet. Have this page as a reference: https://phpspreadsheet.readthedocs.io/en/latest/topics/migration-from-PHPExcel/ Kind regards, Tom

Llewellyn commented

2019-10-01 17:24:43 +00:00

Author

Owner

I have been breaking my head on this, since currently all JCB components are using this lib to import and export values in the back-end.

This means if we make a lib, we need to add the option to package JCB components into a install package as a shipping option, so that the library is also always included. Yet this will make the package very large. So I can see many complain about this.

Next option is to add a validation checker to all install script files that checks if the new phpspreadsheet library is installed and if not gives and error with instructions to first install it. Which again has its drawbacks as it will be like a pain every time you for the first time install a component of JCB you get this error.... man I tell you I am very pressed to treat this the same way I did the first version....

That is to just automatically add the code to all components, but instead of the helper folders... I will atleast move it to the library area and so avoid huge code duplication.

These were my last thoughts before turning my attention to the privacy suite "plugin" add-on for JCB.

I have been breaking my head on this, since currently all JCB components are using this lib to import and export values in the back-end. This means if we make a lib, we need to add the option to package JCB components into a install package as a shipping option, so that the library is also always included. Yet this will make the package very large. So I can see many complain about this. Next option is to add a validation checker to all install script files that checks if the new phpspreadsheet library is installed and if not gives and error with instructions to first install it. Which again has its drawbacks as it will be like a pain every time you for the first time install a component of JCB you get this error.... man I tell you I am very pressed to treat this the same way I did the first version.... That is to just automatically add the code to all components, but instead of the helper folders... I will atleast move it to the library area and so avoid huge code duplication. These were my last thoughts before turning my attention to the privacy suite "plugin" add-on for JCB.

Llewellyn commented

2019-10-20 12:15:13 +00:00

Author

Owner

Okay fist I will add a script to all components who has the old library, that it be removed. Then I am going to go the direction of a silent library implimentation. This means it will add the library to all components and move to the Joomla library folder, so to avoid code duplication. But not as a library package, but with the same script we are managing the phpseclib in JCB.

This for now seems like the best approach, since we get to upgrade, and we get to combine all components to use the same code at the same location in library folder.

@marcodings I will then with every release of JCB run a composer update on this library to insure we stay in sync and so push the changes to all as everyone recompile they will also then get the lattes versions and so on...

Okay fist I will add a script to all components who has the old library, that it be removed. Then I am going to go the direction of a silent library implimentation. This means it will add the library to all components and move to the Joomla library folder, so to avoid code duplication. But not as a library package, but with the same script we are managing the `phpseclib` in JCB. This for now seems like the best approach, since we get to upgrade, and we get to combine all components to use the same code at the same location in library folder. @marcodings I will then with every release of JCB run a composer update on this library to insure we stay in sync and so push the changes to all as everyone recompile they will also then get the lattes versions and so on...

marcodings commented

2019-10-20 12:28:48 +00:00

(Migrated from github.com)

Author

Owner

Seems fine to me. With the exception of not making it a library. Allowing commen access. For BC add some wrapper to all components until one can migrate to "pure" library

Llewellyn commented

2019-10-20 18:05:34 +00:00

Author

Owner

Okay from what I can see in Joomla 3 we are at an impasse that has with it some limitations, here is some respond from stackoverflow and the official documentation for Joomla 3

So adding the phpspreadsheet to the library folder and loading the autoloader when needed seems like the closes we will get at this point.

This is the code I use currently in the helper class of JCB

/**
* Composer Switch
**/
protected static $composer = array();

/**
* Load the Composer Vendors
**/
public static function composerAutoload($target)
{
	// insure we load the composer vendor only once
	if (!isset(self::$composer[$target]))
	{
		// get the function name
		$functionName = self::safeString('compose' . $target);
		// check if method exist
		if (method_exists(__CLASS__, $functionName))
		{
			return self::{$functionName}();
		}
		return false;
	}
	return self::$composer[$target];
}

Then we have another method like this for the phpseclib:

/**
* Load the Composer Vendor phpseclib
**/
protected static function composephpseclib()
{
	// load the autoloader for phpseclib
	require_once JPATH_SITE . '/libraries/phpseclib/vendor/autoload.php';
	// do not load again
	self::$composer['phpseclib'] = true;

	return true
}

This then allows for the following implementation:

[[[Component]]]Helper::composerAutoload('phpseclib');

// now you can use the Library

This is not ideal but works, looking at how the phpseclib guys suggest the implementation we are not that far out.

I am using the phpseclib as the discussion point, since we already have it in JCB and so if it is not done in best practice, I might as well fix it and do the phpspreadsheet the same way. I want to implement this in the most convenient and practical way that also holds to good practice as close as we can within the limitations of Joomla 3. I made the change to the phpseclib only four days ago, it use to live in a vdm_io folder... which I have not removed and placed it in its own folder so other developers will notice it and be more able to also load it in their project, with somewhat the same autoloader helper wrapper. You will see we have these helper method dependent on the phpseclib. So yes, I added them as helpers methods/wrappers since I use them all around JCB and it serves as a convenient way to pull the code without repeating myself.

@marcodings, please explain to me some alternative ways with some demonstration (code) that will serve us better. So to achieve the pure library nature in Joomla 3, since I prefer a best practice approach... no use doing it wrong if better options are available.

It is obvious that I have been using the helper class for a goto in all these kinds of things, and from what I understand it is no longer considered good practice. Yet I have not found the alternatives convenient and practical as yet. But I am willing to learn!

I am actually thinking of moving the whole JCB compiler into a library... and so also many of the functions we now have in the helper class, just every time I think of doing it I get this blank feeling that I am wasting time and should focus on other areas/ideas that do not exist or is no optimal.

Okay from what I can see in Joomla 3 we are at an impasse that has with it some limitations, here is some [respond from stackoverflow](https://stackoverflow.com/a/51878056/1429677) and the [official documentation for Joomla 3](https://docs.joomla.org/J3.x:Using_Composer_with_Joomla) So adding the phpspreadsheet to the library folder and loading the autoloader when needed seems like the closes we will get at this point. This is the code I use currently in the [helper class of JCB](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/componentbuilder.php#L4314) ``` /** * Composer Switch **/ protected static $composer = array(); /** * Load the Composer Vendors **/ public static function composerAutoload($target) { // insure we load the composer vendor only once if (!isset(self::$composer[$target])) { // get the function name $functionName = self::safeString('compose' . $target); // check if method exist if (method_exists(__CLASS__, $functionName)) { return self::{$functionName}(); } return false; } return self::$composer[$target]; } ``` Then we have another method like this for the [phpseclib](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/componentbuilder.php#L4335): ``` /** * Load the Composer Vendor phpseclib **/ protected static function composephpseclib() { // load the autoloader for phpseclib require_once JPATH_SITE . '/libraries/phpseclib/vendor/autoload.php'; // do not load again self::$composer['phpseclib'] = true; return true } ``` This then allows for the [following implementation](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/componentbuilder.php#L3828): ``` [[[Component]]]Helper::composerAutoload('phpseclib'); // now you can use the Library ``` This is not ideal but works, looking at how the [phpseclib guys suggest](http://phpseclib.sourceforge.net/2.0.html) the implementation we are not that far out. I am using the [phpseclib as the discussion point, since we already have it in JCB](https://github.com/vdm-io/Joomla-Component-Builder/tree/staging/libraries/phpseclib/vendor) and so if it is not done in best practice, I might as well fix it and do the phpspreadsheet the same way. I want to implement this in the most convenient and practical way that also holds to good practice as close as we can within the limitations of Joomla 3. I made the change to the phpseclib only four days ago, it use to live in a vdm_io folder... which I have not removed and placed it in its own folder so other developers will notice it and be more able to also load it in their project, with somewhat the same autoloader helper wrapper. You will see we have these [helper method dependent](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/componentbuilder.php#L3976) on the phpseclib. So yes, I added them as helpers methods/wrappers since I use them all around JCB and it serves as a convenient way to pull the code without repeating myself. @marcodings, please explain to me some alternative ways with some demonstration (code) that will serve us better. So to achieve the pure library nature in Joomla 3, since I prefer a best practice approach... no use doing it wrong if better options are available. It is obvious that I have been using the helper class for a goto in all these kinds of things, and from what I understand it is no longer considered good practice. Yet I have not found the alternatives convenient and practical as yet. But I am willing to learn! I am actually thinking of moving the whole JCB compiler into a library... and so also many of the functions we now have in the helper class, just every time I think of doing it I get this blank feeling that I am wasting time and should focus on other areas/ideas that do not exist or is no optimal.

Moving from PHPExcel to PhpSpreadsheet #444

Steps to reproduce the issue

Expected result

Actual result

Additional comments