Thursday, November 2 - 0.3.8 Released with New/Experimental Panel Drafts

thread: 10 messages  |  last: about 5 years ago  |  started: thursday, november 2, 2006, 10:50 am pst


#1  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Thursday, November 2, 2006, 10:50 AM PST

Folks, I just checked in the 0.3.8 pre-release which makes a few small fixes with QQ and qqnodes.

The big new feature that I'd like to get feedback on is Panel Drafts support.

Note that this is currently new and experimental -- the templates are still very much open for feedback/suggestions.

You can try it live at <http://examples.qcodo.com/panel_drafts/> (I don't know if it's an issue with the code or with my internet connection here at the conference, but it seems to be a bit slow/sluggish).

Or you can try it locally by updating to 0.3.8 (locally it works VERY fast and snappy).

please note that there is a new _PANEL_DRAFTS_ constant in configuration.inc.php that you'll need to define.  Also, we've defined some new styles in the styles.css file which you may want to use/adopt, as well.

I've tried putting in the “hooks” where I think people will want to hook in to make customizations to the panelbase code so that developers can more-easily create their own single page application/dashboard pages.

And obviously, the 0.3.8 dashboard which uses the paneldrafts/panelbases will show you, at a basic level, how that works.

But the feedback I'm looking for is for people who are wanting to extend the panelbase code further and make custiomzations for your own application and project requirements: how should these hooks be architected?  What should be changed?  What's missing?  Etc.

Please provide feedback!

#2  |  Kristof Meirlaen (Belgium) Belgium Qcodo Core Contributor
Friday, November 3, 2006, 12:50 AM PST

Hi Mike,

When trying to create a new record by pressing the “create a new ...” button, I get:

 
Fatal error: Argument 3 must not be null in /home/sites/kmeirlaen/kri-soft.be/acc/wwwroot/includes/panelbase_classes_generated/CrediteurEditPanelBase.class.php on line 52

PHP 5.0.4

 public function __construct($objParentObject, $strClosePanelMethod, Crediteur $objCrediteur = null, $strControlId = null) { 

seems to be the cause.

Leaving out the “Crediteur” solves it:

 public function __construct($objParentObject, $strClosePanelMethod, $objCrediteur = null, $strControlId = null) { 

Regards,
Kristof

#3  |  Kristof Meirlaen (Belgium) Belgium Qcodo Core Contributor
Friday, November 3, 2006, 3:41 AM PST

I also have a problem in the normal form drafts:

Fatal error: Argument 2 must not be null in /home/sites/kmeirlaen/kri-soft.be/acc/wwwroot/includes/qcodo/_core/qform/QPaginatedControl.class.php on line 43

Fatal error: Argument 2 must not be null in /home/sites/kmeirlaen/kri-soft.be/acc/wwwroot/includes/qcodo/_core/qform/QFormBase.class.php on line 252

same kind of problem, same kind of solution...

regards,
Kristof

#4  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Friday, November 3, 2006, 11:09 AM PST

kristof... very interesting.  I guess with the 5.1 PHP tree, they added the ability to have nullable strongly typed object parameters for methods... but not with 5.0.

I'll go ahead and update the tempaltes as well as the controls so that it doesn't use them.

Look for this in 0.3.9

Thanks for the post.
--Mike

#5  |  Mike Hostetler (Denver, CO) United States of America Qcodo Administrator
Friday, November 3, 2006, 11:44 AM PST

Hey Mike-

Things are looking good.  I'm happy to see how well the 0.3 branch is moving along.  

One thing I'd like to throw into the pot, please add an 'exit' after a RenderAjax call.  If I output any code in my main script (currently have a debug timer), ajax calls fail because the XML being returned is non-conformant (ie. has HTML in it).

I insert my 'exit' call in line 223 of QFormBase.php.

Thanks,
Mike

#6  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Friday, November 3, 2006, 11:56 AM PST

Actually, I'm a bit hesitant to do that -- because if we exit() out right after rendering the ajax, any potential cleanup or other functionality coded in a Form_Exit would never get run.

Instead, I'd suggest putting debug/output information that you'd only want displayed during a standard (non-ajax) call to be outputted like so:

    if (QApplication::$RequestMode != QRequestMode::Ajax) {
        print('Debug info: ');
        // etc.
    }

This way, you can control that certain debug/other information that you want outputted ONLY get outputted in non-ajax calls... and your XML ajax response can remain pure.

#7  |  Fernando Lordán (Barcelona, CAT, Spain) Spain
Friday, November 3, 2006, 1:19 PM PST

> But the feedback I'm looking for is for people who are wanting to extend the panelbase
> code further and make custiomzations for your own application and project
> requirements: how should these hooks be architected?

I just followed your architecture to acomplish the multipanel page goal. My general class QPage (basically an extended QForm) has Page_Run, Page_Create, Page_Load, Page_PreRender, Page_Validate and Page_Exit overridable hooks, and the panels I put in it inherit the Panel_Run, Panel_Create, Panel_Load, Panel_PreRender, Panel_Validate and Panel_Exit overridable hooks from the generic QPagePanel class (an extended QPanel). It works flawlessy and follows completely the QForm handling philosophy.

How these hooks are implemented, called from QForm, and kept overridable without having to always call the parent hooks is very simple, but it's a thing I cannot explain in two lines. I can send you both class files if you drop me an email address. Mine is “fernando at barnatech dot com”.

#8  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Friday, November 3, 2006, 2:55 PM PST

Thanks fernando -- will do.

#9  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Monday, November 6, 2006, 12:35 PM PST

Thanks to jlehman for pointing this out -- if you run qcodo updater without updating your configuration.inc.php with a new _PANEL_DRAFTS_ directory constant, the updater will give you the following notice:

The Following Errors/Alerts Were Reported
----------------------------------------
Additional Directory Prefix Constants have been added to constants.inc.php since the last time the QCodo Update Service was run.
Be sure and download a new constants.inc.php and update your local constants.inc.php with any new Directory Prefix Constants.  Then re-run qcodo_updater.cli to complete the Qcodo update.

Please note that the system-generated notice should read configuration.inc.php and not constants.inc.php.  Expect this error message to be fixed in the next release (0.3.10)

#10  |  Fernando Lordán (Barcelona, CAT, Spain) Spain
Thursday, November 9, 2006, 2:07 PM PST

Mike, I sent you some files with my extended QPage and QPagePanel solution, but sorry for the lack of explanations (documentation will come some day, you know how this goes).

Just to point a new modification regarding this topic: I've created three new overridable hooks to handle data in QPage and QPagePanels:

- Page/Panel_FetchData(): Literally, to fetch data from the DB (that is, to issue a query to load active records).

- Page/Panel_BindData(): To bind this data from the active record to the form controls.

- Page/Panel_StoreData(): To put the data from the controls into the active record again, ready to be saved into DB with a client issued action.

- Also, pages and panels now have a property flag “RefreshDataOnRequest” that intelligently propagates to child panels.

It works this way:

- For data view pages/panels, you set “RefreshDataOnRequest” to true. This way, _FetchData() and _BindData() are automatically called after _Create() and after _Load(), so after any request you always have a fresh snapshot of the current DB data binded to the controls in your screen.

- For data maintenance pages/panels, you set “RefreshDataOnRequest” to false. This way, _FetchData() and _BindData() are only called after _Create(), so maintenance of the data within the controls is up to the form. The _StoreData method is triggered to put back the controls' data into the active record again, just after _Validate() (if it validates, of course) and just before TriggerActions(). This way, after any request this active record always reflects the data contained in the form controls, and it's ready to be saved with a triggered action.

Also to note: The way all these hooks propagate from pages to panels and from panels to child panels has slightly changed to be more flexibily overridable. So the two files I sent to you don't reflect the current state of things.

Tell me what you think about my solution. I think it's 100% “QCodo-ish”, and it's valid also for people not using QCodo active records made with codegen.



Copyright © 2005 - 2012, Quasidea Development, LLC
This open-source framework for PHP is released under the terms of The MIT License.