losing session element 'pfbc-instances'

[GoogleCodeExporter]

hi again, i'm still trying to use this wonderful class under Joomla!  but
i'm not a strong enough programmer to figure this out.

downloaded the 1.04 version.   (much prefer the CSS approach, thanks).

i'm getting the 'A session is required...' error message from js.php.   but
absolutely have a session, that's not the problem.

so I added the following debug code into js.php just before that message is
posted...  (these look weird, but they end up in javascript)

echo "alert(\"{$_GET["session_name"]}\");"; 
echo "alert(\"$id\");";                      
echo "alert(\"".gettype($_SESSION["pfbc-instances"])."\");"; 

the session_name is something like '50cb5e5e10faa4c47ca1c6437c2f7d09'. 

$id correctly has string 'form_elements'.
but the session element 'pfbc-instances' is NULL.

so i added this line in another part of the program...

echo "<pre>".htmlentities(print_r($_SESSION["pfbc-instances"],true))."</pre>";

and got a valid value that start like
array
(
 [form_elements] => O:4:"form":60:{s:13...
)

i peeked into class.form.php where you set &session_param, and it is being
set correctly to '50cb5e5e10faa4c47ca1c6437c2f7d09'

the generated HTML includes the javascript statement

css.href =
'/community2/components/com_agenda/assets/php-form-builder-class/includes/css.ph
p?id=form_elements&session_name=50cb5e5e10faa4c47ca1c6437c2f7d09';

i use $_SESSION in my other code without issues.

any suggestions?  
thanks in advance.

Original issue reported on code.google.com by tom.bere...@gmail.com on 9 May 2010 at 12:49

[GoogleCodeExporter]

Tom,

Is there anything in the $_SESSION array after session_start is invoked within
js.php?  One thing you could try is commenting out the section of code in
class.form.php where &session_name is appended to the css.php/js.php url.

Keep me posted.

- Andrew

Original comment by ajporterfield@gmail.com on 9 May 2010 at 3:49

[GoogleCodeExporter]

Maybe a better approach would be to comment out the two lines in includes/js.php
where session_name is called before session_start().

Original comment by ajporterfield@gmail.com on 9 May 2010 at 3:54

[GoogleCodeExporter]

after many hours of playing, i know enough about sessions and Joomla! security 
to
diagnose, but not enough to fix the problem.

since there are reputedly 30 million or so Joomla! sites, armies of hackers are
trying to break them - i get about 100 automated attacks on my insignificant 
site
each day.  as a result Joomla! developers have a mania for security.

after a bit of playing, i figured out that the new transaction starting with 
js.php
has a different session_id().   it's a bad idea to send a session_id through 
the URL
because of man-in-the-middle attacks, but i did that anyhow.  but that wasn't 
enough
to restart the session.

so started reading Joomla! source code.   they have their own session handler 
that
seems to pack everything in $_SESSION at the end of each transaction, encrypt 
it, and
tuck it away in the user table of their database.   at the next transaction 
start,
they restore it.  there is no way that I can see for an outside transaction to 
get to
that data.

i found a great site that describes a workaround for Joomla! - basically save 
the
Joomla! session into the Joomla! database as if we were shutting, start a NEW 
session
just with cookies, and then restore the Joomla! session.  but that not useful 
for
most of your audience.
http://pribadidewa.wordpress.com/2008/04/07/session-management-in-joomla/   

ok, we just need to find a way to save your file object and restore it for for 
the
js.php without using Joomla! sessions.   the only clean option i could think of 
was
to put the entire file object into the URL parameter (instead of just the 
session
name).   but pretty sure that's not going to be pretty, or make you happy.   

for now, I'm going to fall back to the 1.0.2 version.  if there's anything i 
can do
to help you move this forward, let me know.

Original comment by tom.bere...@gmail.com on 9 May 2010 at 9:13

[GoogleCodeExporter]

Tom,

Sorry to hear that you're having problems with integrating this project into 
your Joomla! website.  The external js 
and css files were added for xhtml strict compliance.  You should be able to 
use version 1.0.3 without any 
problems.  This version (1.0.3) includes the div layout.  I'll let you know if 
I come up with any ideas on how to 
correct your issue.

- Andrew

Original comment by ajporterfield@gmail.com on 9 May 2010 at 11:50

[GoogleCodeExporter]

i've loaded 1.0.3, it's a charm.

you guys have built something wonderful.   thank you.   it is a thing of beauty.

i've built a wrapper around your library that lets me use a database schema in 
a CSV
file, and generate forms directly from it.   and of course, you have made 
complex
forms like the webeditor and captcha drop-in easy.

but i was probably going to fork your code anyhow.  there are two issues that 
make it
awkward for me to use in it's current form.

1) your class emits code right away.  i program PHP in a CGI style (because i'm 
an
old guy), and i want each call to addElement to return a string, and then 
render() to
return the closing stuff.  

for example, i am building a table where each row includes some update-able 
elements,
like a date.  there's lots of other HTML that gets interleaved into the table 
between
the form elements.  i can't defer until the render().

maybe i'll keep the existing render() function for pure forms and add new 
methods for
messy forms.  but i want the option.

2) there are other form types that i want to add, for example a combo box (a
combination of a text field and a drop-down).  i want to combine your date 
picker
with a time picker to return a single timestamp form element.   

and i want to add some custom map-area images - i realize these aren't 'forms' 
but i
want them to behave as if they were.

in your shoes, i would add a set of methods that allow a new type of form to be
plugged in, and let the community contribute to a library of them.

finally, i'm worried about performance with the js.php approach.   if i have 500
forms (ie: dates) on my screen, i think your code will fire 500 calls to js.php
before it finishes rendering.

thanks again.
tom

Original comment by tom.bere...@gmail.com on 10 May 2010 at 1:33

[GoogleCodeExporter]

Thanks for the feedback Tom.  Best of luck in your development.

- Andrew

Original comment by ajporterfield@gmail.com on 10 May 2010 at 1:56

[GoogleCodeExporter]

just walking through class.form.php to see what i need to change,  you've 
already
done most of the work for me with elementsToString().

that huge block of elseif()...elseif()... elseif()... is dying to be refactored 
into
a set of plugable subclasses - perhaps an abstract factory pattern.

after looking though the code, i'm tempted to keep it almost as is, but let 
render()
return an array of strings or object - perhaps (header, array of fields, 
trailer,
scripts).  the next layer up can consume them as it likes.

i'd love to do that for your project.   but i can't move forward to 1.0.4.

thanks again.
tom

Original comment by tom.bere...@gmail.com on 10 May 2010 at 2:18

[GoogleCodeExporter]

Hi Tom,

At what point is the $_SESSION restored by joomla? Does the class manage to get 
the
$_SESSION for when php_validation fails and refills the form in using the 
$_SESSION?

I don't think the js.php/css.php is a good solution to make the code pass XHTML
validation, for a number of reasons, and in this case its making it very 
difficult to
use the class at all. 

If the $_SESSION is working alright within the main class file, but not in 
js.php and
css.php, then we will need to avoid using external files to the class that 
initialize
a session.

I will try to find the time to propose a patch that generates the form in an 
xhtml
valid manner without utilizing the js.php/css.php solution in the next week.

Also Tom, I would encourage you not to fork the project, as the problems you 
will
encounter will also be by other users of this class, and at the moment the 
class is
quite flexible to change.

Original comment by moncojhr@gmail.com on 12 May 2010 at 2:06

• Changed state: Accepted

[GoogleCodeExporter]

1.0.3 seems to work fine.   i don't have a finished app that processes the POST
values yet, but i can monitor them.   

it may be possible to make the 1.0.4 technique work under Joomla!, but it would 
be
specialized and not useful to the rest of the world.  there are ajax libraries 
for
Joomla!, i haven't figured them out yet.

i'd rather stay with the main trunk - especially if i can contribute to it.  
i've
already refactored a bit so that i can interleave my code between form elements
before rendering.  and i put the jquery js and css files into the header.

if i understand, most of the problem is how to dynamically create a function 
that
looks like:

<script type="text/javascript" defer="defer">
    $(function() {
        var availableTags = ["c++", "java", "php", "coldfusion", "javascript", "asp",
"ruby", "python", "c", "scala", "groovy", "haskell", "perl"];

        $("#datepicker2").datepicker({onSelect: function(dateText, inst) } });
        $("#datepicker3").datepicker();
        $("#datepicker4").datepicker();
        $("#autoselect5").autocomplete({source: availableTags});
                $("#star6").stars({ inputType: "select" });....

class.form.php issues these in little bits and pieces (i've started grouping 
them so
i can interleave my widgets).   maybe it's possible to send this function as a 
text
string or XML, assemble it at the browser, and then run it.   captcha seems 
like the
only major exception to worry about.

let me know if i can help.
tom

Original comment by tom.bere...@gmail.com on 12 May 2010 at 3:00

[GoogleCodeExporter]

Well the reason we do js.php/css.php is because in XHTML you need to define CSS 
in
the head tags.

For JS you must either link off to it, or wrap the javascript in CDATA

<![CDATA[ ]]>

You can only generate the css/js after you know all the form elements etc that 
will
be used.

So andrews's solution is to generate the css/js after the actual form has been
printed and then write js.php/css.php into the head tags, which then use the 
session
to know what had been built.

I think this solution should be rethought, as it is very messy... and rewriting 
the
head tag after the form has been rendered is not real great.

It would probably be better if we forced users to create the form before they 
print
anything to the screen, and then you are able to render the CSS and JS without 
having
to do such trickery.

Andrew mentioned to me that it would be difficult to implement the form with my
solution in some of the projects he is using the form-builder on... so we 
probably
need to think of another solution, or keep the js.php/css.php way as an 
alternative
to my solution, that can be specified when you create the form.

Original comment by moncojhr@gmail.com on 12 May 2010 at 4:22

[GoogleCodeExporter]

Also if you can attach or email me your modified version of the class, that 
would be
useful as it sounds like your changes are heading in the direction I am. Thanks!

Original comment by moncojhr@gmail.com on 12 May 2010 at 4:27

[GoogleCodeExporter]

with abject apologies before you look at it, here's my partially done hack of 
your 
nice code.  i'm part-way through (but stopped for now, it does what i need).

it runs at least some of the demos (the ones i've tested).   

i haven't made it extensible yet.  for that, i planned to change the syntax

$form->addSomething(...) 
to 
$something = $form->addField(new something(...));

which would break all the demos of course.   but now i can work with the 
individual
objects both before and after i bind them to $form.  

- - - 

think about this - if the user wants XHTML compliance, then give an option to
generate the form at the very start of the page, pop out the JS into the 
header, and
then paint the form when appropriate.   that's really easy when the form is 
static
(ie: not data driven).

i have the same problem with jquery - i have one page where i don't know how 
many
elements will be presented (they are embedded in a table).  

OTOH, there may not be much problems with multiple <HEAD> statements if they 
just
hold a script.  it's the other stuff that will drive browsers crazy.

Original comment by tom.bere...@gmail.com on 12 May 2010 at 1:00

Attachments:

• class.form.php

[GoogleCodeExporter]

Hey guys,

Great stuff here.  I just read the last few posts to this issue.  I will second
moncojhr when he discouraged forking the project.  The current js.php/css.php
approach is a solution and not necessarily THE solution.  I'm looking forward 
to see
what you both come up with.  Keep me posted and let me know if there's anything 
I can
assist with.  

Original comment by ajporterfield@gmail.com on 13 May 2010 at 1:39

[GoogleCodeExporter]

The latest release of version 1.0.6 includes a new form attribute - 
preventXHTMLStrict - that you can set in the 
form's setAttributes() function to render the javascript and css inside the 
<body> tag instead of using the 
external js.php/css.php files.  This should fix the session issues that have 
been reported by several in the 
community.  See an example of how this form attribute can be set below.

$form = new form("session_fix");
$form->setAttributes(array(
      "preventXHTMLStrict" => 1
));

Original comment by ajporterfield@gmail.com on 13 May 2010 at 6:54

[GoogleCodeExporter]

I'm considering this issue resolved as the last comment was made in May - 4 
months ago.

Original comment by ajporterfield@gmail.com on 4 Sep 2010 at 5:52

• Changed state: Fixed