Javascript in Add/Edit Block Issues
Permalink
I am building a mutlitable block currently. Much like the core slideshow block, it requires javascript for adding in new elements to the add/edit interface.
I have two problems:
1. Any script tags I create seem to get stripped out of the code once it is displayed. It can be before the divs, after them, inside them, but it always gets stripped out.
2. When I include any script tags, it also screws up the auto-created cancel/add buttons, and they disapear.
How can I use javascript in the add/edit interface? One of the problems is that the block will be using ajax to edit the items, so it needs access to the tools url, which I provide through the controller through a set variable.
I have two problems:
1. Any script tags I create seem to get stripped out of the code once it is displayed. It can be before the divs, after them, inside them, but it always gets stripped out.
2. When I include any script tags, it also screws up the auto-created cancel/add buttons, and they disapear.
How can I use javascript in the add/edit interface? One of the problems is that the block will be using ajax to edit the items, so it needs access to the tools url, which I provide through the controller through a set variable.
I have built quite a number of blocks, so I do understand the concepts.
There are a couple of issues with this, primarily the fact that I need to pass the url for the ajax to the js file, and I don't believe the auto.js file can access the php variables. Even if I was to add it as a variable in my add/edit php file, this gets stripped out. So, the fact that I have a tools url I need to access ends with an endless cycle.
Also, the fact that we have to have our functions stripped out doesn't make sense to me. As developers, we should be allowed that flexibility.
There are a couple of issues with this, primarily the fact that I need to pass the url for the ajax to the js file, and I don't believe the auto.js file can access the php variables. Even if I was to add it as a variable in my add/edit php file, this gets stripped out. So, the fact that I have a tools url I need to access ends with an endless cycle.
Also, the fact that we have to have our functions stripped out doesn't make sense to me. As developers, we should be allowed that flexibility.
Ok, I see now.
Yeah, I don't know why that is happening but one thing I know is that when the block view is rendered, it's searching for the buttons to pass them to the footer of the window.
I just checked some blocks and I can see that including inline JS to take out some PHP variables has been working for me at least. I usually put these on the very top of the add/edit view outside the ccm-ui wrapper. Dunno 100% what JS is run for the view after it's rendered but I believe it shouldn't strip out inline JS.
Have you tried adding some simpler JS to the view so that you can just see if it works at all. I mean like:
One thing that also comes to my mind if browser issues, so have you tried other browser?
Antti
Yeah, I don't know why that is happening but one thing I know is that when the block view is rendered, it's searching for the buttons to pass them to the footer of the window.
I just checked some blocks and I can see that including inline JS to take out some PHP variables has been working for me at least. I usually put these on the very top of the add/edit view outside the ccm-ui wrapper. Dunno 100% what JS is run for the view after it's rendered but I believe it shouldn't strip out inline JS.
Have you tried adding some simpler JS to the view so that you can just see if it works at all. I mean like:
<script type="text/javascript">alert("this is working");</script>
One thing that also comes to my mind if browser issues, so have you tried other browser?
Antti
Have you had a look at AJAX lessons?
http://www.concrete5.org/marketplace/addons/ajax-lessons/...
http://www.concrete5.org/documentation/how-tos/developers/ajax-less...
http://www.concrete5.org/marketplace/addons/ajax-lessons/...
http://www.concrete5.org/documentation/how-tos/developers/ajax-less...
Sorry for the massive delay on this, I've been on vacation.
Yes John, I've seen your exceptionally helpful tutorial. However, my base problem still exists. The very act of adding a script tag to my add/edit code still breaks the block rendering.
Based on your tutorial, I even changed it from the shorthand $(function){} call to the $(document.ready) call you used in your tutorial. The very inclusion of the script tags breaks the block render.
At this point, I think I am forced to show you guys the block. Please forgive any crappy code, I still haven't been able to test it yet (for obvious reasons), and no skinning is done until the code works. Let me know if you have any ideas. Yes, I know the rand etc code is dirty, but it's just a placeholder for now, and frankly should never be run...
Yes John, I've seen your exceptionally helpful tutorial. However, my base problem still exists. The very act of adding a script tag to my add/edit code still breaks the block rendering.
Based on your tutorial, I even changed it from the shorthand $(function){} call to the $(document.ready) call you used in your tutorial. The very inclusion of the script tags breaks the block render.
At this point, I think I am forced to show you guys the block. Please forgive any crappy code, I still haven't been able to test it yet (for obvious reasons), and no skinning is done until the code works. Let me know if you have any ideas. Yes, I know the rand etc code is dirty, but it's just a placeholder for now, and frankly should never be run...
Looking at the block, I am afraid to say either I can't fully understand it, or there is something fundamentally wrong. It looks too complicated for what your requirement appears to be and seems to be missing things needed by the complexity of other parts. I suspect that some of the script is generating incomplete tags or quotes, which sets everything that follows askew. But even with that sorted, I don't think it is a good solution.
My suggestion:
Start from scratch.
Use designer content to generate a block that contains as much of the static structure as possible.
Modify the data XML generated to include an X2 called 'supporter_list' (if you have not already included it)
You don't need the complexities of ajax for an expanding list.
Modify the edit dialog that designer content generated to have an expanding editable list (I wrote a howto on expanding lists/tableshttp://www.concrete5.org/documentation/how-tos/designers/create-a-f... ), with add/delete buttons.
In the save method, serialize the expanding list data into 'supporter_list' (May be best to implode/explode about a text separator than actually serialize/unserialize. that way the supporter_list will remain directly text searchable)
In both the edit and view methods unserialize 'supporter_list' into the editable list data.
In the view, do pretty much what you are already doing to display the list of supporters.
Get this working initially with just plain text for the names of supporters.
Once that is working:
Revise the list of names to include or just be uIDs (if that is what you want), with a user picker.
Revise the storage of supporter list to be a separate table if you really need to (I suspect the serialised supporter_list in an X2 will be searchable enough, but may be harder to manage if there are 1000's of supporters).
The C5 addon 'Contact Dirtectory' may already do what you want - but check first before buying it.
My suggestion:
Start from scratch.
Use designer content to generate a block that contains as much of the static structure as possible.
Modify the data XML generated to include an X2 called 'supporter_list' (if you have not already included it)
You don't need the complexities of ajax for an expanding list.
Modify the edit dialog that designer content generated to have an expanding editable list (I wrote a howto on expanding lists/tableshttp://www.concrete5.org/documentation/how-tos/designers/create-a-f... ), with add/delete buttons.
In the save method, serialize the expanding list data into 'supporter_list' (May be best to implode/explode about a text separator than actually serialize/unserialize. that way the supporter_list will remain directly text searchable)
In both the edit and view methods unserialize 'supporter_list' into the editable list data.
In the view, do pretty much what you are already doing to display the list of supporters.
Get this working initially with just plain text for the names of supporters.
Once that is working:
Revise the list of names to include or just be uIDs (if that is what you want), with a user picker.
Revise the storage of supporter list to be a separate table if you really need to (I suspect the serialised supporter_list in an X2 will be searchable enough, but may be harder to manage if there are 1000's of supporters).
The C5 addon 'Contact Dirtectory' may already do what you want - but check first before buying it.
I also took a look at the block and I'm not completely understanding what's happening there. At least you've got some JS syntax errors there because the $row_include variable is empty which causes an empty row with just a comma in it (= syntax error).
The #1 thing in debugging JS code is to check into your browser's developer console to see any JS errors there that you can fix.
Also, once again good advice from JTF, I'd summarize that by: try something simple first, then try adding more complex UI stuff to that.
Best,
Antti / Mainio
The #1 thing in debugging JS code is to check into your browser's developer console to see any JS errors there that you can fix.
Also, once again good advice from JTF, I'd summarize that by: try something simple first, then try adding more complex UI stuff to that.
Best,
Antti / Mainio
Thanks to both of you. It was a hacky attempt to modify the concrete
slideshow block concept to allow me to do multiple tables, and frankly to
learn a little more about how C5 does this type of thing. It's one of those
things that would have been done in 20 min with just normal code, but
trying to get c5's way of doing it left me struggling. I have done plenty
of ajax in the past, but almost always from scratch, which makes things a
bit easier than working within this type of framework.
I use firebug often, and did use it a bit to debug this code. Unfortunately
the way the block is loaded can cause some issues with finding the code
evals. I copied and pasted a lot around trying to get the structure right,
and obviously I missed parts of it in my battle to figure out where things
went.
John, I'll take a look at your tables link and see if I can work it. You
guys have been fantastically helpful. It's one of those concepts that seems
way harder with c5, but the other aspects of c5 make it worthwhile. I just
need to get the mindset figured out and get a few more full sites done with
it I think.
Thanks again!
slideshow block concept to allow me to do multiple tables, and frankly to
learn a little more about how C5 does this type of thing. It's one of those
things that would have been done in 20 min with just normal code, but
trying to get c5's way of doing it left me struggling. I have done plenty
of ajax in the past, but almost always from scratch, which makes things a
bit easier than working within this type of framework.
I use firebug often, and did use it a bit to debug this code. Unfortunately
the way the block is loaded can cause some issues with finding the code
evals. I copied and pasted a lot around trying to get the structure right,
and obviously I missed parts of it in my battle to figure out where things
went.
John, I'll take a look at your tables link and see if I can work it. You
guys have been fantastically helpful. It's one of those concepts that seems
way harder with c5, but the other aspects of c5 make it worthwhile. I just
need to get the mindset figured out and get a few more full sites done with
it I think.
Thanks again!
With the background you describe, I think once you get the hang of C5 you will find it quicker than what you have been used to for creating a polished and integrated bit of functionality. Certainly that is how I found C5 when I got started (though I still miss the convenience of how Perl does regular expressions)
I think you also need to beware of core blocks. Whilst some of them were 'state of the art' when first created several years ago, in many cases the core team would not make them that way now. They exist in their current form purely because they work and don't need re-writing for any other reason. Since they were written C5 has evolved and there are better ways of doing things.
I think you also need to beware of core blocks. Whilst some of them were 'state of the art' when first created several years ago, in many cases the core team would not make them that way now. They exist in their current form purely because they work and don't need re-writing for any other reason. Since they were written C5 has evolved and there are better ways of doing things.
You guys were right. I was completely overthinking things and not relying on the integrated ability of the save code to remove things by just re-inserting them. John, the tutorial was spot on. The controller code seemed to be perfect, it was just the getting of the values I was trying to do the old fashioned way. Thanks a ton for your help - you helped me comprehend things in a much more clear fashion.
That file is loaded when the editing interface is loaded.
I'd suggest reading some docs:
http://www.concrete5.org/documentation/developers/blocks/understand...