Ajax Header - How to find Post Path?
Permalink
I have looked at the ajaxifying tutorial and John the Fish's tutorial block (and did a search here on the forums, nothing clicked), but I am still dealing with one issue:
I have a package I am working on for a site that is integration with a third party system via Soap calls. I developed most of this before I got here, so I am trying to port my work over.
The issue I have is getting the POST ajax path for the ajax javascript. It is a separate added header item, due to the fact I want to have it segregated, and because of the wide number of calls it handles (and for caching). However, with concrete5 having so many path options, how can I set the path for the POST call to go to? I can't really hard code it, so how do I find it?
A truncated path list to show my concept:
<package>->tools->data_loader_1.php (there are about 5 of these for different functions - and blocks may share them)
<package>->blocks->block_1->js->ajax.js (included by the views addHeaderItem)
<package>->blocks->block_1->view.php (this has some minimal js for interactions, but it is almost all structure).
Hopefully that makes sense, and someone can tell me the best practice for this.
I have a package I am working on for a site that is integration with a third party system via Soap calls. I developed most of this before I got here, so I am trying to port my work over.
The issue I have is getting the POST ajax path for the ajax javascript. It is a separate added header item, due to the fact I want to have it segregated, and because of the wide number of calls it handles (and for caching). However, with concrete5 having so many path options, how can I set the path for the POST call to go to? I can't really hard code it, so how do I find it?
A truncated path list to show my concept:
<package>->tools->data_loader_1.php (there are about 5 of these for different functions - and blocks may share them)
<package>->blocks->block_1->js->ajax.js (included by the views addHeaderItem)
<package>->blocks->block_1->view.php (this has some minimal js for interactions, but it is almost all structure).
Hopefully that makes sense, and someone can tell me the best practice for this.
That's what I was doing for an id I had to set (I made a set function that is called to the ajax file to set the variable).
I'll likely just do it that way. It just stinks sometimes that we can't segregate things better. Such is the price we pay at times for other features.
Thanks for your help!
I'll likely just do it that way. It just stinks sometimes that we can't segregate things better. Such is the price we pay at times for other features.
Thanks for your help!
So, I am trying to move it to methods within the controller (why push info back and forth when I can handle it in a place it is already populated?).
The only irony - I am putting view information in my controller for the ajax return. This seems a little off. Is there a better way of segregating that portion of it out (even an include file so the variables are already there?)
What is the best practice for that situation?
The only irony - I am putting view information in my controller for the ajax return. This seems a little off. Is there a better way of segregating that portion of it out (even an include file so the variables are already there?)
What is the best practice for that situation?
A difficulty with actions in a controller is that they don't work very well during an add dialog. This is a glitch that is easy to miss when developing because you tend to build out from an a block created at the start of development.
For the view-ish parts, I tend to use a library or an element, unless it can be boiled down to a widget of some sort that becomes a helper.
My favoured design pattern changes all the time. But I tend to use package level tools to respond to ajax and re-create an instance of the controller from the bID and cID passed with the ajax call and check security etc.
I can then use the re-created controller to get at the block data, separate models to handle any other data, and libaray or element files for everything else.
For the view-ish parts, I tend to use a library or an element, unless it can be boiled down to a widget of some sort that becomes a helper.
My favoured design pattern changes all the time. But I tend to use package level tools to respond to ajax and re-create an instance of the controller from the bID and cID passed with the ajax call and check security etc.
I can then use the re-created controller to get at the block data, separate models to handle any other data, and libaray or element files for everything else.
Ok, forgive me, I'm new to using C5, so I am still learning everything (first site is nice in that it requires a bit of everything at least, on the other hand it stinks to have to delve so very deep on the first go round).
I originally had this as a package, but I thought it would be easier to test some disparate parts as blocks first, and hard code temporarily the shared piece of info they both use.
The last two paragraphs went way beyond me though. What is the purpose of recreating the controller, and what does it accomplish?
I understand using libraries, tools, etc, and I am indeed moving back to them, as the controller based ajax experiment seems to have more problems than it solves.
Do you perhaps mind taking a little time to explain the last part though? I really do appreciate all the help you have been so far. Time is the most valuable asset we have, and I am so very thankful for all of it you have spent on me.
I originally had this as a package, but I thought it would be easier to test some disparate parts as blocks first, and hard code temporarily the shared piece of info they both use.
The last two paragraphs went way beyond me though. What is the purpose of recreating the controller, and what does it accomplish?
I understand using libraries, tools, etc, and I am indeed moving back to them, as the controller based ajax experiment seems to have more problems than it solves.
Do you perhaps mind taking a little time to explain the last part though? I really do appreciate all the help you have been so far. Time is the most valuable asset we have, and I am so very thankful for all of it you have spent on me.
Let me see if I can summarize what you do, and you can tell me if I am on the right track:
The ajax calls a php file, in the package tools directory.
The top of this uses the cID and bID (although I am not sure the exact calls that enable this) to create a duplicate of the controller. You then query that controller, to get the variables (I am not sure if that is a set/get, or simple php call. I'll use a simple call for the illustration): so $local_variable = $controller->ajax_variable.
That allows the file to have direct access to the info, and then it can go on its way to fulfilling the request.
That would work wonders for me I think.
The exact thing I am doing is accessing a remote system's api using Soap. So, I have nusoap in my libraries (no built in soap library that I see), and a model class that makes the calls to the server (server info stored in the block). The exact php file for the ajax file makes the requisite call and returns a parsed output (which could be done with an included view most likely).
This block has a number of these items. It is an access cable station, so this does ajax calls for show searchings, listings, and specific show info, so it has views for all those options.
This was all created before I got to c5, so I am just trying to port the code over and make it work, but also trying to use best practices and learn the ins and outs of the system. A lot of stations use this software I am querying, so I will likely put it on the marketplace when done. IF I get it done ;). That will require me also finalizing how to do a single page to set a package level variable (in config I assume) that is shared amongst the blocks (server ip).
Phew. Long winded, but it should give a better idea of where I am coming from.
The ajax calls a php file, in the package tools directory.
The top of this uses the cID and bID (although I am not sure the exact calls that enable this) to create a duplicate of the controller. You then query that controller, to get the variables (I am not sure if that is a set/get, or simple php call. I'll use a simple call for the illustration): so $local_variable = $controller->ajax_variable.
That allows the file to have direct access to the info, and then it can go on its way to fulfilling the request.
That would work wonders for me I think.
The exact thing I am doing is accessing a remote system's api using Soap. So, I have nusoap in my libraries (no built in soap library that I see), and a model class that makes the calls to the server (server info stored in the block). The exact php file for the ajax file makes the requisite call and returns a parsed output (which could be done with an included view most likely).
This block has a number of these items. It is an access cable station, so this does ajax calls for show searchings, listings, and specific show info, so it has views for all those options.
This was all created before I got to c5, so I am just trying to port the code over and make it work, but also trying to use best practices and learn the ins and outs of the system. A lot of stations use this software I am querying, so I will likely put it on the marketplace when done. IF I get it done ;). That will require me also finalizing how to do a single page to set a package level variable (in config I assume) that is shared amongst the blocks (server ip).
Phew. Long winded, but it should give a better idea of where I am coming from.
Yes, pretty much it.
The below is a reply I wrote earlier, then put on hold while the C5 site maintenance was on, then had my dinner, now a last check before shutting down for the night.
>>>>
A block controller automatically has the block's data, so if I need to do anything with the blocks data during an ajax action, I find the easiest way to do it is to create an instance of the block controller and then call methods in that. I pass the bID and cID back with the validation token in the ajax request.
Usually it is just reading some block configuration settings. But the interaction between the tool and the controller can be more involved, especially if the tool is running a dialog.
Elements are another way of loading code, a bit like inlining separate code (ie no subroutines or objects), but with a little bit of namespace protection. They are usually a good way of breaking view like stuff into separate files. For example, a form that is popped up by a tool, an element for each tab of a complex dialog (useful in view, edit, tools and single pages). They can also be good for sharing common stuff between views (A library can also be used for all that sort of thing).
A model is just an object (pretty much the same as a library) that encapsulates some data or data like behaviour. While a block has a closely coupled row of data that maps to it 1:1 and is automatically available in the block controller, if there is other more complex data it is usually managed by a model.
The below is a reply I wrote earlier, then put on hold while the C5 site maintenance was on, then had my dinner, now a last check before shutting down for the night.
>>>>
A block controller automatically has the block's data, so if I need to do anything with the blocks data during an ajax action, I find the easiest way to do it is to create an instance of the block controller and then call methods in that. I pass the bID and cID back with the validation token in the ajax request.
Usually it is just reading some block configuration settings. But the interaction between the tool and the controller can be more involved, especially if the tool is running a dialog.
Elements are another way of loading code, a bit like inlining separate code (ie no subroutines or objects), but with a little bit of namespace protection. They are usually a good way of breaking view like stuff into separate files. For example, a form that is popped up by a tool, an element for each tab of a complex dialog (useful in view, edit, tools and single pages). They can also be good for sharing common stuff between views (A library can also be used for all that sort of thing).
A model is just an object (pretty much the same as a library) that encapsulates some data or data like behaviour. While a block has a closely coupled row of data that maps to it 1:1 and is automatically available in the block controller, if there is other more complex data it is usually managed by a model.
Ok, so I understand the concept, but I am not finding how to recreate the controller, so if you could help me there, I would appreciate it.
So, first I checked to see if I could just instantiate a new controller with an id. No go, because that would just be too easy.
I am gathering from your comments that I will need to use both cID and BID, although I would think normally BID would be enough.
My research has led me down this path, so I would appreciate a heads up to verify I am looking in the right place.
First of all, will I need to load helpers to do this?
$bid from Post
$bo = Block::getById($bID);
$bc = new BlockController($bo);
bc->get('variable');
Thank goodness netbeans allows you to search for declarations, since finding things in the folder structure can be rather unfun...
So, first I checked to see if I could just instantiate a new controller with an id. No go, because that would just be too easy.
I am gathering from your comments that I will need to use both cID and BID, although I would think normally BID would be enough.
My research has led me down this path, so I would appreciate a heads up to verify I am looking in the right place.
First of all, will I need to load helpers to do this?
$bid from Post
$bo = Block::getById($bID);
$bc = new BlockController($bo);
bc->get('variable');
Thank goodness netbeans allows you to search for declarations, since finding things in the folder structure can be rather unfun...
This is a stripped down version of the design pattern I have been using, mostly from within the view. The bID is needed to recreate a block's controller. I find I often use the cID within a block controller because I have been doing stuff that is page related (so if a block is in a stack, I need to know what page is rendering it).
Any tool using bID will fail if the tool is called from within a block add (bID does not exist yet). In that case, all the needed data from a not yet added block has to be in the ajax request parameters.
Also, if it is called within a block edit, the bID will change immediately afterwards (changes with new version saved), so that has to be taken into account.
(This has beeen stripped down from something more complex, so there could be glitches in it where I have edited and removed stuff)
Any tool using bID will fail if the tool is called from within a block add (bID does not exist yet). In that case, all the needed data from a not yet added block has to be in the ajax request parameters.
Also, if it is called within a block edit, the bID will change immediately afterwards (changes with new version saved), so that has to be taken into account.
$vf = Loader::helper('validation/form'); $vf->setData($_REQUEST); $vf->addRequiredToken('my_tool_name'); if (!$vf->test()) { die("Access Denied - Missing Token."); } $bID = $_REQUEST[bID]; if (empty($bID)){ die("Access Denied - Missing Bock Identity."); } $cID = $_REQUEST[cID]; if (empty($cID)){ die("Access Denied - Missing Page Identity."); } $other_data = $_REQUEST[other_data ];
Viewing 15 lines of 32 lines. View entire code block.
(This has beeen stripped down from something more complex, so there could be glitches in it where I have edited and removed stuff)
More advanced than I am ready for yet I think, but I definitely get the concept. I'm sure after a few sites this will all come so much easier. I just hate the time crunch of trying to learn everything at once, but I was boxed into a corner and basically didn't have a choice.
Thanks a ton!
Thanks a ton!
Example in block controller, get tool to the view
(there is also a similar way of doing block tools)
Once in the view, you then need to pass it into the script
So with this you would need script in your view to pass it to the separately loaded script.
Another trick is to attach the tool name (and any other script parameters) as a data attribute to something in the DOM.
With that, your separately loaded script can find what it needs by looking in the DOM.