javascript inside modal window

[Rob Stocker]

Hi All,

I've been working on this joomla game for some time now, and have re-factored my code on numerous occasion as I try to come to grips with mootools.

The game works like this:  There is a grid of cells. Each cell is a div with an image. Most cell images have a link to a modal window with varying content. This content is usually a tmpl file from a view.

So from my view folder  I have several views eg building, person, car

Each view then may have several sub templates options  like building_items, building_weapons, building_bank. They are called by  placing

<?php echo $this->loadTemplate ($this->buildings->option); ?>  at the bottom of the main view templ eg building.php


Originally I was using squeezebox to load the tmpl view into a modal window, but whatever cell info was clicked first would load in each subsequent click regardless of what cell I clicked. So on Matt's suggestion I changed the links from rel=squeezebox to rel= iframe. This kind of worked but I dislike iframes and it created the need to reload CSS,  javascript etc for each view template.

By accident I dropped the rel=xxx and simply left the class= modal and for some reason this removed the weird cacheing issue (I am convinced this is a joomla bug).  And thus I continued.

Here's the issue:

I wanted to have the main javascript in one big file. This file contains stuff like character motion, worlds rules etc. Then in each subtemplate eg building_items.php or building_bank.php I would have the specific javascript for a shop building or a bank building etc.

While I was using iframes this was fine because each modal contain all the javascript pertaining to that building only. But if not using iframes the javascript in the tmpl file ie the file that is called inside the modal, is not being executed.

One option was to move all the code into the main JS file and use if statements or case switches to decide which building javascript to call but this is just another workaround. And at this point I am tired of having workarounds bite me in the ass.

So how can I get the javascript to be called from a tmpl modal window?  Why might it not working in the first place? Is this something to do with mootools scope?

Rob

[Rob Stocker]

Hi All,

If anyone wants to check out a working model of the game, I've turned off the need to login or register. Just use the cursor keys to move about or click on an object to see the modal windows in action.

Rob


http://www.eclecticmeme.com/index.php?option=com_battle&view=single

[Techbot]

Hi All,

Can I assume that mootools is not supported in this group? I've not been having much luck with it and would rather start looking for an alternative than getting stuck with no solution in sight. I have tried on the mootools forum but I'm guessing it's joomla's implementation that's tripping me up. Or what I'm attempting is simply not possible.

Any advice here would be sincerely appreciated as I've been going round in circles for weeks. I start this project to learn how to code for joomla but I guess I should have stuck to a project that was php only.

Rob

[elin]

Rob ,

We don't have a guaranteed turn around time. 

 It might  be helpful if you restated the issue; reading your first post I see a number of different questions and comments. Short, sweet, to the point is he way to go.   Picking the one you want help with the most is probably a good strategy for getting replies. Also remember that the rest of us have no idea about this previous discussion with Matt. Reading your post I'm not clear even clear how you are getting to the modals. Remember that most people are responding while on coffee breaks :P. They don't have time to read a long complex story or to ask you a ton of questions to get the relevant information.

Obviously Mootools must work fine in modals since we're using select and filters and sliders and tabs and other javascript in modals all the time. 

My advice is to try isolating the issue  by using sliders or tabs first. Does your code in the subtemplates work inside a slider and in a tab? If so, that's great we know the issue must indeed be something related to the modals.  Is it all code that doesn't work in the modals or just your code? For example can you ... put tabs in your modal?  Are you positive the uri for the js file is working as expected in the modal? Are you sure all necessary behaviors are there?

You might also want to show the code you are using in the subtemplate. 

Elin

[Ian MacLennan]

I'm not entirely sure what the issue is that you're having.  Did you post it somewhere?

Regards

Rob

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Rob Stocker]

Hi Elin,
 thanks for the response.

 I was not in any way hinting at anything negative. I am simply wondering how well is mootools supported in this particular forum.  Since this is the second time I have asked similar questions and received only one reply, I was simply trying to confirm whether I was approaching this (both my coding and asking for help) the correct way or whether most people were like me in that they associate joomla coding with php only and mootools is kind of secondary.

Being asked to restate the question is exactly what I needed and I sincerely thank you for that.

My original question is here https://groups.google.com/forum/#!topic/joomla-dev-general/JJ9zffJxGjY

I think  calling a community builder page inside a modal window might be the best way to demonstrate this, since it is not my code.

<a class="modal" href ="index.php?option=com_comprofiler&task=userprofile&tmpl=component&user=<?php echo $player_id; ?>" title="<?php echo $player_id ?>">

The profile page will appear but the javascript menu items are all displaying instead of only the menu headers.

 I have several other pages to call inside modals and they all use completely different code- none of them work and I can tell from firebug that they are not being called.

If however I use an iframe and relink the javascript like thus

<?php
 include_once ( $mainframe->getCfg( 'absolute_path' ) . '/components/com_battle/includes/JIGS.js.php');
?>

everything works as it should, but it means I have to relink the CSS. More importantly it means I must centralise all the individual javascripts into one big file, breaking the modular framework and increasing the individual page loads.

I hope this shows that it is not the javascripts themselves that are the issue but how I am calling them.

My suspicion is that because it is mootools, I cannot simply append the scripts to the individual  template files, but must somehow extend the mootools class (?), or something similar.

thanks for your time

Rob

[Ian MacLennan]

Do you have a live example of the menu not loading properly?

Ian

[Rob Stocker]

Hi Ian,

http://www.eclecticmeme.com/index.php?option=com_battle&view=single

I have turned off all the other characters, so if you click on the warrior type guy (not the karate dude) you can see the menus.

thanks

Rob

[elin]

What I'm finding confusing is what link you are using to load just a subtemplate. Linking to a CB page with a normal url is something very different .... even linking to an MVC page like index.php?option=banners&view=clients&tmpl=component  is something really different than trying to isolate one subtemplate.

Sorry maybe I'm just being dens on this but instead of a subtemplate have you thought about making a separate layout for each?  index.php?option=com_battle&view=single&layout=whatever ?

Elin

[elin]

Aren't those tabs JQuery and not Mootools?

Elin

[Rob Stocker]

Hi Elin,
 the reason I am using sub templates is because 50% of the template will be consistent across each of the views, eg view/building/tmpl/default.php 

The remaining subtemplates being based on the individual building type for example view/building/default_bank.php or view/building_shop.php

 (using community builder was a bad example.)

But even something as simple as the following will not work if it is placed in the code that is to be shown in the modal

alert();

function alert(){
 alert('this is a test')
}

The point being the GAME view is loaded normally first eg view/game/tmpl/default.php  and therefore "on dom ready" etc will  be executed. So when I click on a link that brings "fresh" BUILDING view content into the modal, it is is not a page load but a page append. Whereas if using an iframe it would be a page load (I hope this makes sense- I don't actually know what a modal does, and this is my issue) and therefore any javascript code in this building view or "page append" is ignored because it did not exist when the GAME view was originally loaded.

If I move all this code into the GAME view ie is present during the initial page load before the modal is called then the code works. This completely breaks up the modular structure, because it means I have to place ALL the different BUILDING view javascripts, (let's say there are seven building types) into the GAME view and use case-switch statements to choose which one to execute  ( and several more negative consequences).

Rob

[Mark Dexter]

Hi. I'm somewhat of a newbie when it comes to JavaScript, so I apologize if I'm off base here. We recently added a plugin event called onBeforeCompileHead that, if I understand correctly, is specifically designed to allow to put stuff into the head element just before it is rendered. Could you use this to load the javascript you need? For example, could you load just the JS you need for a particular menu item in a plugin using this event? Mark

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25.03.2011 14:25, Rob Stocker wrote:
> Hi Elin,
> the reason I am using sub templates is because 50% of the template will be
> consistent across each of the views, eg view/building/tmpl/default.php
>
> The remaining subtemplates being based on the individual building type for
> example view/building/default_bank.php or view/building_shop.php
>
> (using community builder was a bad example.)
>
> But even something as simple as the following will not work if it is placed
> in the code that is to be shown in the modal
>
> alert();
>
> function alert(){
> alert('this is a test')
> }
>

Well, since nobody here seems to be familiar with SqueezeBox/MooTools,
I'll give it a try (though I'm not an expert in how Joomla integrates
SqueezeBox).

=> You said earlier, that you do *not* use the iframe handler of SqueezeBox.
That's *exactly* the reason, why it does *not* execute any JavaScript in
it's content. Apparently, you are using either "adopt" mode or "ajax"
mode (I don't know which one, because I don't know which default is used
by Joomla in the SqueezeBox's initializer-options).

If using "ajax" mode, you can set ajaxOptions.evalScripts to true, like
this (JS-Code):

options = {handler: 'ajax', size{x: 500, y: 400}, ajaxOptions:
{evalScripts: true}};
SqueezeBox.initialize(options);

Joomla's PHP equivalent would be (i believe):

$mopts = array('handler' => 'ajax', ... , 'ajaxOptions' =
array('evalScripts' => true));
echo JHTML::_('behavior.modal', $mopts);

Have a look into media/system/js/modal-uncompressed.js
At the beginning of this file, you see all the supported optons and
their defaults.

If you are using "adopt" mode however, then you are pretty much on your
own, because in that mode, JavaScript (re-)execution doesn't make much
sense and therefore is is not implemented at all. Theoretically, you
could do that from within an event handler. However: Specifying an
event-handler requires it to be a JavaScript object of type "function",
*BUT* Joomla's JavaScript wrapper (which is responsible for converting
PHP arrays into JavaScript objects) does not support that. (It only
supports strings, booleans, numbers and sub-objects). So it basically
boils down to initializing SqueezeBox yourself from within JavaScript.

E.g.

1. Do *not* use JHTML::_('behavior.modal'); // Doesn't support
eventhandler functions.
2. Instead, use JHTML::_('behavior.mootools');
3. Then, in your invoking page header, initialize SqueezeBox yourself:

window.addEvent("domready", function() {
var game = new myCuteGameClass();
var opts = {
handler: 'adopt',
onOpen: game.onOpen.bind(game),
size: {
x: 500,
y: 600,
},
// ... other options
};
SqueezeBox.initialize(opts);
// The following is actually only needed, if you want to
// stick to Joomla's mechanism of instrumenting onclick
// events into all A-Elements of class "modal".
// Instead, you could call SqueezeBox.fromElement(...)
// programmatically. The argument of $$() has the same
// syntax like a CSS-Selector.
$$("a.modal").each(function(el) {
el.addEvent("click", function(e) {
new Event(e).stop();
SqueezeBox.fromElement(el);
});
});
});

4. In your event handler, iterate over all DOM-Elements of the modal
content, and for each script object, call eval (resp. mootool's $exec).
E.g.

var myCuteGameClass = new Class({

initialize: function() {
// whatever ...
},

onOpen: function(content) {
content.each(el) {
// check el for type 'src/javascript'
// if true, check for text, if non-empty
// exec it, otherwise check for src, if
// non-empty, load and exec it.
}
}
});

Hope, this gives at least some hints...
- -Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD4DBQFNjRtmboM4mAMyprARAkK8AJUcV0UYlsPJosASHsQmbvdScO0QAJ0d6HBa
1INvivGsMIeEEMgHQnixcA==
=ED6T
-----END PGP SIGNATURE-----

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25.03.2011 23:47, Fritz Elfert wrote:
> On 25.03.2011 14:25, Rob Stocker wrote:

...

Another tip for debugging JavaScript in Joomla using FireBug:

Use J1.5, not J1.6.
Reason:

In 1.5, Joomla checks for the string 'konqueror' in the User-Agent
header. If it finds it, it sends the -uncompressed variant of all
scripts like mootools etc. So you fetch some FF-Plugin for altering your
User-Agent, use that to append 'konqueror' to your User-Agent and voila,
JS-Debugging in FireBug made easy.

In J1.6, this useful check is gone and you only can enable uncompressed
scripts by enabling the global debug flag. This however is bad because
as a side-effect, you get tons of debugging-output in which you are not
really interested and which destroys your carefully designed page-layout
of the modal content.

- -Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjR6wboM4mAMyprARApnZAJ4+wOV5svHrr/eGmsHLNAv9SLGBugCfZCjL
b78BnhQy4HZijbz+o6B3o0A=
=4xFL
-----END PGP SIGNATURE-----

[Mark Dexter]

Fritz, it would be great if you had a specific suggestion for how to make this work better in 1.6. Even better would be to suggest a patch. Thanks! Mark

-----END PGP SIGNATURE-----

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25.03.2011 14:25, Rob Stocker wrote:
> I don't actually know what a modal does, and this is my issue

Umhh just noticed that, ok - you probably should read my responses in
reverse order ;) otherwise me talking about SqueezeBox doesn't really
makes sense:

Joomla's "behavior.modal" uses a script named "SqueezeBox", which uses
MooTools and which facilitates the creation of a lightbox filled with
content from a varety of sources: url's inside iframes, iframes filled
by JS-HTTPRequests, content aquired by MooTool's "adopt" method from an
existing DOM-Tree, images...

BTW: This script has it's own homepage:
http://digitarald.de/project/squeezebox/

In Joomla, this script is normally used in one mode only: The 'iframe'
mode. If you write JHTML::_('behavior.modal'), then this triggers
several actions:

- - mootools.js inclusion is added to the headers (if not already added)
- - modal.j (which contains the SqueezeBox code) is added, (again, only if
not yet doen)
- - In the head section of the document, an event handler for the domready
event is installed which instruments all A-Elements of class "modal"
with onclick-handlers invoking SqueezeBox.fromElement(...)

So: When using Joomla's "modal" (with default settings), you actually
use SqueezeBox's 'iframe' mode to load another Joomla page inside that
iframe.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjSSpboM4mAMyprARAhTVAJ4y/AaV9YrmOFcSw/zGKnode4kouwCgpFq3
yi81Pq9D58/hdo8gcxraxiY=
=2og5
-----END PGP SIGNATURE-----

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.03.2011 00:13, Mark Dexter wrote:
> Fritz, it would be great if you had a specific suggestion for how to make
> this work better in 1.6. Even better would be to suggest a patch. Thanks!
> Mark
>

No problem. Ad hoc, three solutions come to mind:

1. (Re-)add a check for a specific string in the User-Agent (just like
in J1.5) - simple.

2. Add another global debug variable, just for javascript - again: simple.

3. Extend the global debug flag to be used as a bit value instead of
just a boolean. Then assign bitmasks to various debug categories like
JDEBUG_MASK_DB, JDEBUG_MASK_FOO, JDEBUG_MASK_BAR (similar to PHP's error
stuff) one of them could be JDEBUG_MASK_JAVASCRIPT - complex, lots of
changes all over the code ... but most versatile and extendable.

For 1. and 2. i could have a patch by next week. For 3. i'm afraid I
have to postpone that until I finished the my component's support for
J1.6 (in about 2 weeks).

So, which one would you like?

- -Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjSkYboM4mAMyprARArGfAJ9DgYW89HxJjlGQfm5JbQFiG9apDwCZAetw
vz/537JWpMCs/A76dMMH7Yw=
=VYRm
-----END PGP SIGNATURE-----

[Mark Dexter]

Thanks, Fritz. Off the top of my head, I like option #2. Option 1 is fine also, but it seems like it is a bit more obscure (like something you just have to know). Do you have a preference between 1 and 2?

Option 3 seems a bit over the top to me.

Does anyone else have an opinion on this? If not, I'd say option 2.

Thanks. Mark

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.03.2011 00:51, Mark Dexter wrote:
> Do you have a preference between 1 and 2?

My personal preference is 1.), because you can enable/disable debugging
just by setting your UserAgent string. No action on the server-side
required. This has been *very* handy in the past when doing support for
Users - just visit their site with your modified UserAgent and be able
to set breakpoints in JavaScript right away.

- -Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjS1/boM4mAMyprARAlflAKCCDkDbI0SxN4NgjeWaqvchPuT/TQCeLnJY
7AnOHo5Yai4B7hC/L4WpFtM=
=DzxR
-----END PGP SIGNATURE-----

[Mark Dexter]

In that case, I would agree and say go with option (1). If you can get a patch done, I'll try to get it into the next release. We are planning to freeze trunk for the release of 1.6.2 in about 1 week, so if you can get it done in the next few days, we can try to get it into 1.6.2. Thanks. Mark

-----END PGP SIGNATURE-----

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.03.2011 01:08, Mark Dexter wrote:
> In that case, I would agree and say go with option (1). If you can get a
> patch done, I'll try to get it into the next release. We are planning to
> freeze trunk for the release of 1.6.2 in about 1 week, so if you can get it
> done in the next few days, we can try to get it into 1.6.2. Thanks. Mark

Just got a better idea (a mixture of 1 and 2): Like in (2), use a
separate debug flag, but add a single global check for the UserAgent
string which can set this flag.
This reduces the checking part to a single function in the code (not
like in 1.5 where those checks were spread all over the code) and also
gives the ability to enable it from both backend and via UserAgent...
The changes in existing code would be even less.

I think I'll do that one.

-Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjTPTboM4mAMyprARAsI1AKCMsKabmnmEe0z3irjRzj10ZISsMgCgmJUo
ExA6WhFSiIr7uER0ehjrDT4=
=yxr/
-----END PGP SIGNATURE-----

[Mark Dexter]

Sounds great to me. Thanks. Mark

-----END PGP SIGNATURE-----

[Ian MacLennan]

I have also found myself in situations where it would be useful to be able to get uncompressed javascript output.

I don't like the idea of using the user agent - that was intended to workaround Konqueror issues - not specifically for debugging javascript.

I would be more in favour of another debugging parameter called 'Javascript Debugging' or something like that which would have three possible settings:

    1. Off (default)

    2. On (Switchable)

    3. On (Permanent)

Setting 1 and 3 should be self explanatory.  Setting 2 would add a check for a request variable that could be used to turn debugging on or off for the duration of the session.  This would be a lot easier to work with and would be a lot more accessible than having to set the user agent.

Note that this would also make it possible to set it in the browser since you could create a cookie in your browser with the request parameter which would be sent on every request.

Is that something that seems useful?

Ian

-----END PGP SIGNATURE-----

[Mark Dexter]

@Ian: This seems very reasonable to me.

@Ian and Fritz: Since you guys know way more about this than I do, I will happily bow out of this conversation.

Thanks. Mark

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.03.2011 03:30, Ian MacLennan wrote:
> I have also found myself in situations where it would be useful to be able
> to get uncompressed javascript output.
>
> I don't like the idea of using the user agent - that was intended to
> workaround Konqueror issues - not specifically for debugging javascript.
>
> I would be more in favour of another debugging parameter called 'Javascript
> Debugging' or something like that which would have three possible settings:
> 1. Off (default)
> 2. On (Switchable)
> 3. On (Permanent)
>
> Setting 1 and 3 should be self explanatory. Setting 2 would add a check for
> a request variable that could be used to turn debugging on or off for the
> duration of the session. This would be a lot easier to work with and would
> be a lot more accessible than having to set the user agent.

I like the idea of having 3 states. This way, admins can decide if they
want to make this feature accessible remotely or not.

What I don't like is the Request-variable. I personally find the
UA-header less intrusive, especially if you don't change the original
content but just append some keyword.
Having it in a regular request is more intrusive. Cookies, POST- or
URL-params are processed by Joomla's "regular" request handling. This
could - in theory - lead to different code paths depending on existence
of the debug param. (Just imagine some extension handling a GET request,
checking if there are any request parameters at all.) The UA however is
normally only checked for specific fragments like "Mozilla" etc, never
for equality of the whole UA string. Therefore, a change of code paths
other than setting the debug flag is *very* unlikely.
Furthermore, setting a Cookie requires one additional Request/Response
cycle to precede the actual debugging. Again, this can have side effects
on the state of the debugged code.

About ability to set the keyword:
All major browsers - even IE - have support for changing the UA either
natively, or a plugin is available for that.

- -Fritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjWnSboM4mAMyprARAl3zAJ9w6otJfn9oTTaRyOzJ372g6KE0TACfWgnR
Dzr3zWCYbinhigbPCUgTe34=
=VcW0
-----END PGP SIGNATURE-----

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.03.2011 03:30, Ian MacLennan wrote:
> I have also found myself in situations where it would be useful to be able
> to get uncompressed javascript output.
>

I've added Item #25454 in the Feature Request Tracker with a patch
against trunk attached.

I implemented Ian's suggestion of having a 3-state setting and - for now
- - implemented my variant of using the UA header. But that can easily be
changed in just 2 lines (one code line, one description tooltip in the
language ini). Let's see if there are more opinions than just ours.

- -Fritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNjW7nboM4mAMyprARAo6JAJ9/QPYuhOwqEsYSxwYppDJAmKnwigCeL2PC
kBMadzJuUKw4peG9p43BRgM=
=DoxQ
-----END PGP SIGNATURE-----

[Rob Stocker]

Hi All,
Big thanks to Fritz ,Elin and Mark.

Plenty here for me to digest over the coming weeks.
Nice to think my post indirectly lead to a patch.

Rob

-----END PGP SIGNATURE-----