-
-
Notifications
You must be signed in to change notification settings - Fork 177
032 JCB manual custom code implementation
Automatic import of custom code during compilation. This is one of our latest features that's been added to the JCB component. 00:00:16 I'm happy to demonstrate it to you since all it's functionality is in place. I explain to you some of the limitations that currently still exist. Hope that it will become a very useful tool to all of you out there. First what does it do? Well it is actually a little mutated from what it's original intent was and it's become two things. The first thing is, (and this is obviously what was initially 00:00:52 intended) is that you would be able to add code to your component, once it's been compiled and installed into that same Joomla website. That you be able to go into that code, and with a few placeholders add code, 00:01:21 that once you compile the component again, JCB would dynamically grab that code extracted into its database, store it there. And from there on forward continue to add it back into the component every time. The way we've done that, we have not used the line numbers as the main 00:01:50 way of determining where that code must be added. Because of the reality that line numbers always will change. You might have the custom code that you're adding, you said line 105 or something, and if you make it change at line 20, that means all the code moves down of course and now we don't know where to add your code 00:02:19 without either writing over or placing it before, there's all kinds of complications. So the only way we could resolve that is to create what we 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.
If you want to see how we do it, there is the code is open source, so you can go look at it. So there is a function in the aget file, which is part of the 00:03:22 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 save 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. I'm very sure there are better ways to do this. We will constantly improve this as others makes suggestions, and make sure that it remains stable. But to to explain why it sometimes 00:04:27 uses more or less of the lines above, it should never use more than 8 lines. Because here it is packing the fingerprint, taking the line content putting it into an array. Every time it passes, it checks whether that array is greater than 10, we cut it down to 6. 00:04:54 This continues to happen over and over and over because we don't want this fingerprint array to become bigger then 10 lines. At some point when we find a placeholder, we actually take that fingerprint array, we create a hash from it, then we store that hash into the database. 00:05:24 That means that amount of lines are changing. Because we have just cleared the array and we are at 6 lines. Then we add a 7th and now we find a placeholder and everything happens.
There are two ways in which the code is added. I have explain that in the previous tutorial, but I can do that again. 00:05:56 In that same file there is a comment way at the top, which gives their explanation of the placeholders. The placeholders these X s here, must be asterisks. There like that one(///[INSERT<>$$$$]///). 00:06:26 This is the one with which you would start either to insert or to replace.
There is also a note on GitHub about this which may be more logical. So here we are at Github. It's on issue 37 if you want to go look at it under the Joomla component on GitHub 00:06:55 the component builder on GitHub. Basically to start inserting code, you would use this(///[INSERT<>$$$$]///) as a placeholder, then your code on a new line, then when you're finished this(///[INSERT<>$$$$]///) would close that code block. Sometimes you don't want insert code, you want to replace code that was generated by JCB. Then you'd use the replace code placeholder(///[REPLACE<>$$$$]///). And then again use this(///[REPLACE<>$$$$]///) one 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 from replaced. It adds it back without this diamond(<>) in between those dollar signs and inserted text or replaced text. 00:07:55 It removes them because basically by doing that, it means that this code doesn't need to be updated. The moment you add those two back in there between those 2 values, next time component builder compiles. It actually knows this piece of code I need to check again and update whatever is in the database, because it's been changed. 00:08:25 This diamond here tells it. There is a change you need to update. You will see that there is this new number being added next to the code. That number is actually the id of the database row 00:08:49 that JCB is actually stored the code in. So if you change this number, you are going to have a problem. So don't change this number. JCB put this number in that he can know where to go update the code in the database. Once you've made any changes to the code, you would simply add this diamond(<>) back in, that's quite important otherwise it will not be 00:09:18 be parsed, and it will be overwritten by what's in the database. That's the initial purpose of this new feature, was to be able in the editor, create code and then on the fly, have it become 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 00:09:47 remember it. If you want to change the code you just add these diamonds(<>) either for the insert or for the replace depending on what you did. It will automatically know there's been a change and it will first update what is in the database, and then store it back into the new compiled version. That is exciting in itself I realize 00:10:12 it's a real stunning new feature. We have been doing some teething on some of its implementation. You can even read down here. There's some comments and things. We are at the moment at version 2.3.2 which is not yet released. I'm busy working on it because this new version 2.3.2 will include 00:10:41 the extra feature which wasn't ever really discussed here on the forum. Because it was a feature that I've been hoping for quite some time. I've build quite a number of components with JCB by now. I've always had this issue that I would develop a very smart function, a custom script, inside of some view or some field or somewhere in JCB. I would like to use it again elsewhere 00:11:15 but then I have to copy it, go pasted there. And it will happen that I would improve it there. Add this little thing there and I debug this. Improve the whole function, maybe just pieces script or whatever, I just improves it. And then it where I took it from does I need to know copy again back there. It's always this copy and move and then obviously there's variables inside that needs to be different names. 00:11:47 This always been a very unpleasant experience.
Since I know of object orientated concepts, I've always wondered is there a way for me to with JCB create the same kind of in a small way of course, give that some kind of functionality. 00:12:09 When this new improvement came along immediately thought yes there is a way for us to make this work for both of these aspects. What did we do? Well I created the option for you to either I used the hash automation, which is the one I've just explained or to use the JCB manual. 00:12:47
Now JCB manual if you setup custom code, the JCB manual will do exactly that. It will literally create the option for you to take this placeholder(customcode). For example I have a field, let me open it. 00:13:47 I have a field which I upload images.
It is this little drag and drop field. Is actually and note as you can see. I'm using some HTML in the description and I've added some JavaScript to this footer of wherever does field is being used. This code 00:14:16 is used to upload or it's part of the process, there is much more code but this is what I need 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. For example that word teaser, needs to be different everywhere else and the word image. Sometimes it must be 00:14:48 images and not just image. What I've done, is I've actually taken this code, I've added it to a custom code. I have set, this is JCB manual, and everywhere where I want dynamic script updates, I've added the 'arg' values. If you want to understand more about the 'arg' values just read this note above here. To make it simply 00:15:19 arg. These arg areas is like placeholders. I can pass strings or values via this custom code placeholder and it gets updated on the fly during compilation everywhere where I used this code snippet elsewhere in JCB. 00:15:44 This gives me a little 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's by far not error proof there, you can't use any commas, and plus signs in these values. It needs to be 00:16:15 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 pasted 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 they doesn't have a value for it. Now what I'm doing is, back into the field, I add the placeholder here. Since it is id 1, I am passing three values to it, 00:17:28 image, image and teaser. Which will then correspond to the replacing arg values here. 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 I'm able to reuse this code anywhere else in JCB. So far I have saved this previously. I'm 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.
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.
- Home
- Beta Testing
- Custom Code
- PHP Settings
- Demo Component
-
Tutorials
- Hello World JCB
- Intro JCB Guide
- JCB Installation Steps
- Planning Components
- Field Type Overview
- Basic Fields Creation
- Admin View Management
- Advanced Field Usage
- Admin Component Integration
- Component Setting Customization
- Scripting Components
- Component FTP Options
- Dynamic Get Method
- Site View DynamicGet
- Site View Templates
- Template Setup Guide
- Layout Configuration Steps
- Custom Admin Management
- Adding Site Views
- Custom Admin Integration
- MySQL Demo Tweaking
- Global JCB Settings
- Custom Time Field
- User Helper Integration
- Email Helper Usage
- Message Store Email
- List View Unescape
- Export Import Customization
- Overwrite Custom Fields
- List Field Filtering
- Automatic Code Import
- Manual Code Implementation
- Component Export Import
- Custom Admin Buttons
- Translation Management
- Site View Permissions
- Component SQL Updates
- Site Edit Configuration
- JCB Backup System
- Helper Structure Integration
- JCB v2.5 Upgrade
- Tab Setup Guide
- JCB v2.6 Release
- Extended HelloWorld
- Field Rule Validation
- Community Snippets Intro
- Snippet Forking Tutorial
- Pull Request Snippets
- Library Manager Area
- Excel-based Translation
- Dynamic Router Details
- Database Auto Updates
- Subform Quick Demo
- VDM Package Import
- Dynamic File Inclusion
- File Field Upload
- Drag-n-Drop Upload
- Quick HelloWorld JCB
- Non-database Fields
- Dashboard Customization
- Menu Prefix Toggle
- Community JCB Packages
- Collaborative JCB Workflow
- JCB Package Install
- JCB JAB18 Event
- Convenient New Fields
- Component Language Strings
- Library Functionality Anticipation
- Join Field Relations
- License Template Change
- Code Reusability
- Local Dev Environment
- Extended Field Types
- Joomla Custom Fields
- Custom Field Expansion
- Site View Listing
- Run Expansion Method
- Form Site View
- Field URL Update
- Additional Helper Methods
- Field Validation Rules
- New Placeholder Feature
- Component Config Params
- Per-field Default Values