XH 1.7: sprint #6

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: XH 1.7: sprint #6

Post by Holger » Wed Apr 05, 2017 1:39 pm

Sorry, can't follow you anymore.
The only thing I need is something (or exactly the same) like XH_afterPluginLoading() right before the final ?> in cms.php.

For example
cmb wrote:XH_beforeOutput()
The code of this function is similar (or in fact a duplicate) of XH_afterPluginLoading(). So it becomes possible to register a function to manipulate the complete generated html with the help of output buffering.

If you see another chance to catch the complete output (beside userprelude.php) it would be fine with me. But I don't think so.
And, as I said before, if you think such a hook is not useful in general, we can leave things as they are...

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Wed Apr 05, 2017 2:07 pm

Holger wrote:Sorry, can't follow you anymore.
I'll try to explain what this code does:
  1. start output buffering
  2. include the template (or use the fallback template)
  3. store the CSRF token in the session
  4. call XH_finalCleanUp()
This is actually simplified, but basically that's what's normally happening.

So calling a callback at the very end of cms.php is basically the same as calling this callback at the start of XH_finalCleanUp().
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: XH 1.7: sprint #6

Post by Holger » Wed Apr 05, 2017 4:47 pm

cmb wrote:I'll try to explain what this code does:
Ahh :idea:
And asking the manual makes things much clearer:
php.net wrote:The function will be called when the output buffer is flushed [...] or when the output buffer is flushed to the browser at the end of the request.
I thought the callback function will be called immediately :roll:

So your former suggestion with the two hooks
cmb wrote:And, well, the end of cms.php is actually just before XH_finalCleanUp() will be called, so we may even have two hooks, maybe XH_beforeFinalCleanUp() and XH_afterFinalCleanUp(), even though I don't like the term "final cleanup". The PHP manual calls the respective paramter of ob_start() $output_callback, and maybe we should adopt this abstraction (after all, registered callbacks might do anything but cleaning up), and rename XH_finalCleanUp() to XH_outputCallback(), and add hooks to register callbacks, namely XH_beforeOutputCallback() and XH_afterOutputCallback()?
seems to be a nice solution.

Thanks (again) for teaching me the basics :)

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Wed Apr 05, 2017 5:42 pm

Holger wrote:I thought the callback function will be called immediately :roll:
Fine that this is solved. :)
Holger wrote:So your former suggestion with the two hooks
[…]
seems to be a nice solution.
I'm not sure if we really need both hooks. I guess in your case hooking at the end of XH_finalCleanUp() would be fine; otherwise you'd have to handle $bjs separately, as it gets injected into the HTML only at the end of XH_finalCleanUp().

But note the path issues I've mentioned above (second half of the post). (a) we need some way to find the install folder (current working directory), and (b) users hooking into XH_finalCleanUp() would have to bear in mind to use it for all filesystem paths (but not URL paths). (a) isn't a problem, but (b) might cause confusion (I've stumbled several times over this issue when trying to debug inside XH_finalCleanUp() without a debugger – really nasty).

Anyhow, I'll set up a feature branch with both hooks tonight, so you can do some experiments.
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Wed Apr 05, 2017 11:32 pm

cmb wrote:Anyhow, I'll set up a feature branch with both hooks tonight, so you can do some experiments.
Done, so please check it out on occasion, and compare XH_beforeFinalCleanUp() with XH_afterFinalCleanUp(). I still think that the former is unnecessary.
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: XH 1.7: sprint #6

Post by Holger » Thu Apr 06, 2017 9:51 pm

cmb wrote:so please check it out on occasion
Okay, after fiddling around with the correct notation of the callback function ( I should learn to RTFM :roll: ), I was able to do some testing. And, of course, it works as expected. And you're right: things like filemtime($source) are not working without XH_CWD.
So I'm really happy for the moment :D .
cmb wrote: ... and compare XH_beforeFinalCleanUp() with XH_afterFinalCleanUp(). I still think that the former is unnecessary.
Hmm, I can't imagine a real use case for XH_beforeFinalCleanUp() at the moment too. Maybe we should drop it.

Thanks for your endless support!

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Fri Apr 07, 2017 3:56 pm

Holger wrote:So I'm really happy for the moment :D .
Fine. :)
Holger wrote:
cmb wrote: ... and compare XH_beforeFinalCleanUp() with XH_afterFinalCleanUp(). I still think that the former is unnecessary.
Hmm, I can't imagine a real use case for XH_beforeFinalCleanUp() at the moment too. Maybe we should drop it.
ACK. Unless someone else has objections, I'll remove it before submitting the PR.
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Sat Apr 08, 2017 11:11 pm

cmb wrote:perhaps just two functions: one for linking of stylesheets, and one for inclusion of JS files, similar to ::addScript() and ::addStylesheet()) might simplify things
Hm, I have some doubts whether including JS by PHP generated <script src="…"> links is future proof. New JavaScript syntax has been rolled out with a considerable speed in the last view years, and any script using only a single new syntactic construct would miserably fail on old browsers. Therefore, it doesn't make sense to even deliver such scripts in the first place; instead the script loading should be triggered by JS, guarded by some CTM[1], and the initialization would be a few lines at most, so it could be written into the document (i.e. the generated HTML) directly. The latter could still use something like ::addScript(), though, in which case it might make sense to offer a variant (or even to restrict to this variant) that does the details (namely to create, configure and insert the desired <script> element) behind the scenes. An alternative might be a general loader (or even a depency checker) written in JS, but even that would still require to somehow get started, i.e. to emit a minimal <script> element. However, all such <script> elements could be joined into a single one.

Another option would be not to use newer JS syntax, but rather to stick with what ES 3 offers. While some may consider this a viable option nowadays, it certainly isn't forever.

[1] CTM (whichever variant) is certainly no proper feature detection, but rather mostly unrelated existence inference. However, at least nowadays it appears to be a rather pragmatic solution.
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: XH 1.7: sprint #6

Post by Holger » Wed Apr 12, 2017 10:32 am

Thanks for the interesting links. I would welcome to have a better and modern API for handling JS (and CSS). And I think we should not wait too long. But for now, we should concentrate on 1.7 until we have a first stable release.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.7: sprint #6

Post by cmb » Wed Apr 12, 2017 11:09 am

Holger wrote:Thanks for the interesting links. I would welcome to have a better and modern API for handling JS (and CSS). And I think we should not wait too long. But for now, we should concentrate on 1.7 until we have a first stable release.
ACK.

But actually, it isn't only about JS and CSS, but about third-party PHP libraries too. Consider, for instance, PHPMailer. If it's used by two or more Plugins in the same request, that might easily cause a fatal PHP error ("Cannot redeclare class PHPMailer"). But even if the plugin checks for class_exists(), it might get an unsuitable version, potentially leading to hard to find errors. Okay, PHPMailer offers a $Version that can be checked, but not all libraries may do so.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply