032 JCB manual custom code implementation

JCB MANUAL CUSTOM CODE

Brief Explanation

00:00:00

Automatic import of custom code during compilation. This is one of the latest features that has been added to the JCB component. Although all its functionality is in place there is currently some limitations which exist that need to be explained. First, what does it accomplish? It actually mutated from that which its original purpose had been and became two things.00:00:52 The first thing is, (and this is obviously what was initially intended) that it will be possible to add code to the component once it has been compiled and installed into that same Joomla website, then to be able to go into that code, with a few placeholders add code, that once the component is compiled again, JCB would dynamically grab that code, extract it into its database, store it there and from there on forward continue to add it back into the component every time. 00:01:43The way it have been done was that the line numbers had not been used as the main way of determining where that code must be added. The reality is that the line numbers will always change. It may be Custom code that is added, for instance line '105', and if it is made to change at line '20', that means all the code moves down of course and it is impossible to know where to add your code without either writing over or placing it before, there are all kinds of complications. So the only way to resolve that is to create what had been initially called the fingerprint, but later became a hash reference of the code, a few lines of code above the custom script, and a few lines of code below the customs. 00:02:50 It varies from how many lines it uses. There is a reason for it.

Updating Code From JCB In The Editor

00:03:01

If you want to see how it had been done, the code is open source, it is possible to go and look at it. There is a function in the 'Aget' file, which is part of the compiler a set of files. The functions name is 'searchfilecontent'. It's in this function that it really goes through every line of the code that is already on the Joomla website. When it finds it, it adds it to an array which eventually gets saved to the database. This is the lines that actually does the work. 00:03:53 There's lots of things that works with this function, but this is the center of everything. There are better ways to do this. It will constantly be improved and insured that it remains stable as suggestions is being made. 00:04:27 It should never use more than 8 lines as it is here where it is packing the fingerprint and takes the line content and place it into an array. Every time it passes, it checks whether that array is greater than 10, and should be cut down to 6. 00:04:54 This continues to happen over and over because this fingerprint array should not become bigger then 10 lines. At some point when a placeholder is found, the fingerprint array is taken, a hash gets created from it, then it is stored into the database. 00:05:24 That means that amount of lines are changing. Because the array has been cleared and are at 6 lines. Then a 7th gets added and now we find a placeholder and everything happens.

Quick Explanation - Insert/Replace

00:05:43

There are two ways in which the code is added. It has been explained in the previous tutorial, and will be explained again. In that same file there is a comment way at the top, which gives the explanation of the placeholders. The placeholders, these X's here, must be asterisks. Like this one(///***[INSERT<>$$$$]***///). 00:06:26 This is the one with which you would start either to insert or to replace.

GitHub Explanation For Update And Insert Issue 37

00:06:33

There is also a note on GitHub about this which may be more logical. It's on issue 37 under Joomla Component Builder on GitHub. Basically to start inserting code, this (///***[INSERT<>$$$$]***///) is used as a placeholder, then your code on a new line, then when finished, this(///***[INSERT<>$$$$]***///) would close that code block.

Sometimes you do not want insert code, but want to replace code that was generated by JCB. Then the replace code placeholder(///***[REPLACE<>$$$$]***///) may be used and again use this one(///***[REPLACE<>$$$$]***///) to end the code block. 00:07:25 Now when Component Builder on compilation discovers these tags(///***[INSERT<>$$$$]***///)(///***[REPLACE<>$$$$]***///), they get converted to from insert to inserted and from replace to replaced. It adds it back without this diamond(<>) between those dollar signs and the inserted text or replaced text. 00:07:55 It removes it by doing that, it means that this code does not need to be updated. The moment those two are added back between those 2 values, when Component Builder compiles. It interprets that this piece of code need to be checked again and update whatever is in the database, because it has been changed. 00:08:25 This diamond here indicates it. There is a change that needs to be updated. There is this new number being added next to the code.00:08:49 That number is the ID of the database row in which JCB had stored the code in. If this number is changed, a problem will occur. NB. Do not change this number. JCB had placed this number in, in order to know where to go to update the code in the database.00:09:18 Once any changes had been made to the code, simply add this diamond(<>) back in, that's quite important otherwise it will not be be parsed, and it will be overwritten by the content in the database.

The initial purpose of this new feature had been to be able to, create code in the editor and then on the fly, make it part of the JCB infrastructure for your component. Then in the future it will continue adding that code back in without you having to write it, or to remember it.00:09:47 If it is necessary to change the code, just add these diamonds(<>) either for the insert or for the replace depending on what has been done. It will automatically update what is in the database, and then store it back into the new compiled version.

00:10:12 It is a stunning new feature. There had been some challenges on its implementation. There is some comments to look at. We are at the moment at version 2.3.2 which is not yet released that will include the extra feature which have not been discussed on the forum. A ideal had been born to develop a very smart function, a custom script, inside of some view or some field or somewhere in JCB and to use it again elsewhere but then it have to be copied, and pasted and then improved. Then get this(See video) added and get it debugged, improve the whole function, maybe just pieces of script. Then it is a tedious task to copy it back from where it have been taken and then there is variables that need to be considered which need to have different names. 00:11:47

Custom Codes In JCB

00:11:52

Since I have some knowledge of object orientated concepts, the idea emerged to create with JCB the same kind of functionality. When this new improvement came along, the possibility to make this work for both of these aspects became clear. What has been done? The option had been created to use the hash automation, which is the one that has just been explained or to use the JCB manual.

Placeholder

00:12:47

If the Custom code is set up, the JCB manual will create the option for you to take this placeholder(customcode). For example: Open this field. Here is a field with which images are uploaded.

• Example Field

00:13:52

It is a drag and drop field. It is actually a note as may be seen. Some HTML is used in the description and some JavaScript is being added to this footer of wherever this field is being used.00:14:16 This code is part of the process, there is much more code but this is what is needed to reuse quite often. I improve this in many areas and then I would always have to come back here(JavaScript). There are certain text that differs from each place. 00:14:37 For example: The word 'teaser', needs to be different everywhere else and the word 'image', sometimes it must be 'images' and not just 'image'. This code has been taken and added to a custom code. Set it as JCB manual, and in all places where dynamic script updates are needed, the 'arg' values are added. More info about the 'arg' values may be read in this note above.(See video) 00:15:19 To make it simply 'arg'. These 'arg' areas is like placeholders. Strings or values may be passed via this Custom code placeholder and it gets updated on the fly during compilation everywhere where it uses this code snippet in JCB. 00:15:44 This gives me a bit of that object orientated feeling where I write a function or a piece of script once, then I can reuse it everywhere else, and simply update the values being passed to it. It is by far not error proof there, you can not use any commas, and plus signs in these values. 00:16:15 It needs to be one word. It can have a dollar sign if you want to have it place a dollar sign symbol in the code, but it doesn't execute the string that you pass. It will literally just paste it in wherever you've placed this 'arg' placeholder. You can add as many values to this 'arg' values as you want. Always make sure that the amount of values that is in the code must correspond to the amount of values that you are passing to it. 00:16:54 Otherwise you would end up having a certain area of the code, the 'arg' placeholder will not be replaced with anything. It will stay like that if it does not have a value for it. Back in the field a placeholder is added. 00:17:28 Since it is 'id 1', three values gets passed to it, 'image', 'image' and 'teaser'. Which will then correspond to the replacing arg values. So that '0' would be 'image', this '1' value here would be 'image', and this '2' would be 'teaser'. It will actually replace it on compilation. Now it is possible to reuse this code anywhere else in JCB. It had been saved previously, so I am going to close it and open another one. 00:18:03<<<<<<<<<<<<<<<<<<

I've got one here called poster. Which is basically doing the same thing. Now I'm also passing image, image and then poster. That means on this area it will change that 2 arg value which is actually the third one. It will update it to poster instead and so I have 00:18:29 the ability to have dynamic code in custom code, which can be reused all over JCB.

Differnce Between Editor Changes And Custom Code Changes

The only negative thing currently is that this kind of code that has dynamic values past to it, will not be updated by any changes you make in the editor outside of JCB. If you think about the 00:18:58 two functions you'd realize that they do not fully merge at this stage. Let me say this if you have a snippet of code which has none of these arg, for example if you only used it like this, without any extra values, that code will be replaced, if you make any changes to it in the editor. 00:19:32 So it will start behaving like the initial implementation. It will place it back into the component with that inserted tag above it, and if you put the diamond in like we explained, it will get this inserted tag. If you have a custom code to which you not passing any values, then it will add this inserted around it and you can then in the editor add a diamond. And then on compilation it will update that code in JCB and then place it back into the new compiled component. 00:20:16

That still works, and I think it's amazing that it does, but unfortunately the moment you pass any arguments to it, like so(see video), then we know that there are arg placeholders in the Script like that. And since the script is now being used at multiple areas with multiple values. Now let's say you change one of them, you don't really want it to replace the database script, because how will we know where these arg placeholders should be placed. 00:20:53 The code at that stage has no reference whatsoever to these arg values. Now there is an idea busy formulating which we would ideally move all the arg values up above your script. (see video)Like this maybe put some 00:21:14 convention of arg's, like that and then arg and then equal and then change this to value var, in this case, because it's JavaScript and that could possibly start resolving the issue. 00:21:45 I'm still working on it. Which then we would only really not update this area in the database. But update the whole rest so you would then in that case use value where ever arg0 is to be found. (see video)Then we need only take care of this area and this area can be dynamically updated. I haven't actually find a complete satisfaction with this solution. 00:22:22 I'm still working on it. But I can guarantee you that it is something I would like to be able to do, is to make a change to the editor and it also updates it here in the database. I think that would be excellent. But for now any code with args as long as this note remains here, I think we said here, that if there is any change to these limitations, these notes will change. Next time you open it and you see the note is different you would be as happy as we are with the 00:22:56 advance. That is really the other feature that we've now add. Basically creating custom code and then reusing it across multiple areas of your component, without the old complexity of needing to update it every where again. You need to know your PHP and whatever language you are targeting with this custom 00:23:28 code well enough so that you by this placeholders and by everything else that it actually works. If it does not work that debugging and everything unfortunately is your responsibility.

There is another thing that is still functional though. I think I didn't mention it yet, that's the component placeholder, and the view placeholder. If this specific script is going to end up somewhere under a specific view, 00:24:02 because your field script, this field script gets added to the view footer. Then you have a view placeholder which basically is just also (((view))). So that's how you could then do a view dynamic update of anything, if you need to use the view string name any where in the script. That means you have component with the uppercase[Component] 00:24:39 and all uppercase and all that variations. And you have the view unfortunately, only that current view that is being targeted will be added to that placeholder in lowercase. 00:25:11 I will compile this now and then in the code show you where it's been added. A component that it's using that at the moment is registry. I'm going to install it now. Let's go look at the code where it should have been added. 00:25:41 So in the code we see there the image is being updated with image. Teasers have been placed there, images been placed. There as well as in all the other areas where we had those arg placeholders, they've all been updated. The code itself has been inserted in the correct area. That is custom code in a little different implementation of it we've called that the 00:26:14 JCB manual option. If you want to know more about the hash automation option, then please watch the previous Tutorial On YouTube.