Forums

While trying to add AJAX feature to my form, I use the EXTRA1 field, which I call through JSON.
Something similar to the topic in this thread: http://www.chronoengine.com/forums.html?cont=posts&f=2&t=12838&start=15.
The URL I use 'index2.php?option=com_chronocontact&chronoformname=my_form_name&task=extra&format=raw' works fine from the frontend, but not from the backend.

Any idea?
Emanuel.

Hi Emanuel,

Possibly an extra /administrator/ is added in the back-end url. Try using a full url including the domain name like JURI::base().'index.php?option=com_chronocontact&chronoformname=my_form_name&task=extra&format=raw'

Bob

Thanks Bob,
I tried the full path (both using JURI or hard-coded), but with no success.
By the way, I'm developing locally, but I don't think it has something with the URI problem.

Emanuel.

Hi Emanuel,

Hmmm . . . don't know what else to suggest. What are you trying to achieve with the link from the back-end?

Bob

Hi Emanuel & Bob,
Though I havn't verified that this indeed is the issue, as I recall, the main site and admin end uses different session IDs (though they use the same storage). This would cause the tokenCheck to fail, as the security token is unique to the session - not the user.

The session cookies have different domains for the site and the admin end, so even though you click in the admin end, the URL points to the live site.

I don't remember at the moment if the tokenCheck affects the extra tasks. However, if you use the session storage, or make assumptions as to user's logon status, this will most likely break.

I'll see if I can't look deeper into this tonight..

/Fredrik

Hi Fredrik,

I'm 99% certain that the task switcher is after the Token check.

Bob

Hi Emanuel & Bob,
I just dug through the source, and found a very interresting thing:
[list]

If you call the extra task using task=extra, the tokenCheck() will not be in effect.

If you call the extra task using task=send&action=extra, the tokenCheck() will be in effect.

[/list]
Since this topic deals with the first case, my first suspicions are not the case. The session storage and logon username/status would still be "unlinked" to the logged on user in admin end, so if your JSON-handler depends on these resources, that would be a plausible cause for the malfunction.

/Fredrik

Hi Bob & Fredrik,
This different session and token issues are really interesting (you just opened a way for a solution I'm looking for in another issue...).
But I'm not sure if this is the case here.
The only connection to the user is the access to the back-end and to the form in the front-end (limited to 'manager' group). I don't pull any user data.
I 'just' trying to chain two SELECT lists, each gets the data from a different table.

It works perfectly in the front-end, but not in the back-end.
The logic I use: main table gives me a reference id. Then I use jason.remote to send it to extra1 (using '&task=extra' . I don't define the extraid). Then I do a simple query to the second table, generate a select.genericlist using JHTML and send it back using json_encode.

This is the code I wrote in the Form JavaScript field:

<?php
$document =& JFactory::getDocument();
$script = "
window.addEvent('domready', function() {
$('artist_id').addEvent('change', function() {
//e = new Event(e).stop();
var subject_container = $('subject');
var aid = $('artist_id').value;
var url = '".JURI::base()."index2.php?option=com_chronocontact&chronoformname=photosbe&task=extra&format=raw';
subject_container.innerHTML = 'Working on the subject list...';//temporary progress message
var jSonRequest = new Json.Remote(url, {
	onComplete: function(r) {
subject_container.innerHTML = r.html;
	}
}).send({'aid':aid});
  });
});
";

$document->addScriptDeclaration($script);
?>

And this is the code in Extra code 1:

<?php
    $json = stripslashes($_POST['json']);
    $json = json_decode($json);
    $db =& JFactory::getDBO();
    $query = "
      SELECT `id`, `subject`
      FROM `#__aa_subjects`
      WHERE `artist_id` = ".$db->quote($json->aid).";";
      
     $db->setQuery($query);
     $subjects = $db->loadObjectList();
     $options = array();
     foreach( $subjects as $subject ) {
       $options[] = JHTML::_( 'select.option', $subject->id, $subject->subject );
     }
$list =& JHTML::_( 'select.genericlist', $options, 'subject_id', null, 'value', 'text', '', 'subject_id' );

if( !$list ) {
   $response['html'] = '';
}else{
   $response['html'] = $list;
}
?>

I looked at the switch 'extra' > then 'doextratask function' > then doExtra function which all are simple and straight forward, and couldn't see why the URL should be different when calling it from the back-end.

Emanuel.

Hi Emanuel,
Rather than using JURI::Base(), consider using JURI::Root(), as the Base method will preserve the /administrator part of the path for the admin end. Root will not.

Keep in mind that the admin end, technically speaking, is a separate application from the live site. Thus, the tasks that one component provides on the live site is not automatically present on the admin end, unless explicitly provided there by the admin-part of the component (if any). For ChronoForms, only the live site provides the ability to display and submit user created forms (including the extra tasks). The admin end provides the ability to create/edit/delete forms, and view/delete submitted data stored in the DB.

That means, http://www.example.com/index.php?option=com_chronocontact&chronoformname=test&task=extra will work, but http://www.example.com/administrator/index.php?option=com_chronocontact&chronoformname=test&task=extra will not.

/Fredrik

Thanks Fredrik.

I got it now!
I thought it is obvious that getting to the form through the connections manager>show data>edit will work the same as getting to the form from the front-end, but it isn't (after your explanation I went through the different tasks switching in the back end and couldn't find any function to deal with 'extra').

So sending the json to the extra at the front end, though I'm in the back-end, does the work (using JURI:root() to make sure the 'administrator' won't be part of the URL ).

Thanks again,
Emanuel.