2.0

Objective

For the next release of Zoop, The 2.0 release we should have a compelling set of changes. The purpose of this document is to outline some of the largest changes. Some may spill over into a 2.1 release which is fine.

Solution

Portero will largely benefit from a strong Zoop 2.0 release. We don’t believe that another framework can displace Zoop currently, we tried, so let’s bring Zoop into the forefront with the following features.

Timing

Beta releases in November, release in December (or January).

Features

Zoop already has a full feature set. These changes will improve Zoop’s interoperatibility, especially as it pertains to large scale rapid development.

Model

Doctrine as an optional Model component (ORM).
Formz integration with Doctrine
- Validation
- CRUD

Controller

Support for Key Value path parameters (both zone and page params)
- Use a “:”, ie. app/zone/key:value/page/key:value/key:value/key:arr_value1:arr_value2:arr_value3
Support for arrays as path param values, see above example.
API style format support. Different format support in the controller..
- Pass along a requested format, XML, JSON, PDF, HTML, etc... controller function will return a dataset in that format.
- Possible implementation example
  - URL -> /people/steve.francia/profile.XML || profile?output_format=XML || Request Header = “Text/XML”
  - Controller recognizes this and calls page_method which populates $zone->output_data, which it returns in the requested (XML in this case) format.
Create a CRUD base zone for working with a given table.
- Has view, edit (create), delete, etc already present.
- Define which table (Doctrine Object).
- Let base zone and forms do the rest. Really useful for quick prototyping & admin interfaces.
Pagination support.
Fix catchall issue that hurts SEO
- pageIndex will answer requests to http://host/zone/
- pageDefault will answer requests to http://hosts/zone/a_string_that_doesn’t_match_any_pages
  - Default to a 404 header
- Requests to http://host/zone redirect 302 to http://host/zone/

View

JQuery Integration with Forms and Ajax interactions

Misc

Documentation, Documentation, Documentation
Ability to load Zend Framework Components
- Particularly 3rd party services
Perhaps other frameworks (Code Ignitor?)
Split up some files, more abstraction, better for extendability
ACL & Role support
General Cleanup
Support better configuration system (YAML)
Integration from Rick’s Experimental Branch
Community
S3 Support!!!
Cleaner App Structure
Better support / documentation for cli setup tools
Version bump everything.

Calling Stored Procedures - Mysql

Hi Guys,

Just wondering how could I call a mysql "Stored Procedure". I have already tried using "sql_query" but it only returns procedure and the parameters being called i.e. is not executing.

Cheers

Controller Zone and Page Parameter Handling

New Page Param handling

First, cause it’s easier.

Page parameters will now support a new structure.

old method:

http://host/zone/zone_param/page/pageparam

new method:

http://host/zone/zone_param/page/pageParamKey:pageparam/pageParam/pagePa...

New Functions:

$zone->getPageParam($name);$zone->getPageParams();

The latter will return an array of the page parameters.

an example:

http://host/zone/zone_param/page/Foo:Bar/Tar/Zoo:Far:Jar

$zone->getPageParams();

would return:

array(
    [Foo]     => Bar,
    [1]     => Tar,
    [Zoo]    => array (
            [0]     => Far,
            [1]     => Jar
              )
    );

The $inPath param is no longer needed, but remains unchanged for compatibility reasons.

New Zone Param handling

Zone parameters now have a good amount of new functionality and additional flexibility. The general use is the same. You still need to define the zone Param names which is a fixed number so the URL can be effectively parsed.

New SPECIAL WILDCARD param names.

*

equal to {0,..}

+

equal to {1,..}

{min,max}

min is numeric max is numeric or ‘..’ which represents infinite.

?

equal to {1,1}

Caveats

The wildcard params require the new key:value structure.
Wildcard params are necessarily greedy. * or + will expand to eat every contiguous key:value pair param. Thus, two wildcard params cannot be next to each other. If you really need two sets of wildcard params, put a named parameter between them.
Obviously if you are using the new key:value params you can’t use a “:” char in your named params.

Logic

The logic is simple if there is a fixed count it works as before. If there isn’t a fixed count then the last param is found by finding token before the instance of a token without a “:” char. These special param names can be used interspersed among standard param names.

zone_name/zone_param/?/*/zone_param/+/page_name/page_param

Operation

Works similarly to page params. Keys become the param names and will appear mixed in with the standard zone param names. Supports key:val1:val2:... as [name] => array( val1, val2, ...).

The new methods operate similarly to the correlating page methods.

$zone->getZoneParams()
$zone->getZoneParam($name)

ayuda

nuevamente les pido ayuda a cualquiera que me la brinde por fa necesito aprender a manejar correctamente el framework ayuda

ERROR BD FUNCTION column y assoc

por favor una ayuda en estas dos funciones que estan mal o algo asi

Fatal error: Call to undefined method PDO::getAssoc() in C:\xampp\htdocs\zoop\db\PDO_database.php on line 183

View 2.0

The Zoop Framework Gui object (the View) is getting a few new tricks for the 2.0 release. Stay tuned for details.

Default template set

View 2.0 will ship with a default set of sane templates, located safely inside the framework codebase. A skeleton app will no longer be required to have a bunch of templates lying around just because they might be required by a component. This way the framework can guarantee that base templates exist and will be available, but they can be overridden at the app level if desired.

Default templates will be shipped in ZOOP_DIR/gui/templates. The generic layout templates are in the ZOOP_DIR/gui/templates/base folder. A template for the formz component might live at ZOOP_DIR/gui/templates/forms/formz.tpl

Templates are easily overridden in View 2.0. Any template file include is checked first at the app level. If the file exists in the app, that template is used. If no app template is found, Smarty will fall back to the supplied framework template resources. So the template at APP_DIR/view/templates/blank.tpl will override a default template located at ZOOP_DIR/gui/templates/blank.tpl

Improved CSS and JavaScript includes

View 2.0 makes it easy for a component to include CSS or JavaScript for output. For example, the Formz component might want to assign some default styling and javascript fanciness for form elements. The zoopfile zone will be leveraged to expose these framework resource files to the web.

global $gui;
$gui->add_css('zoopfile/formz/css/formz.css', 'zoop');
$gui->add_js('zoopfile/formz/js/formz.js', 'zoop');

This snippet ensures that the formz stylesheet is included any time a Formz object is displayed by Zoop.

Two levels of priority are available (passed to $gui->add_css() and $gui->add_js() as the second parameter). Files that are part of the framework should be designated 'zoop', as they will be output before the app level stylesheets and javascript files. This allows application developers to easily override default styles and javascript defined by the framework.

To render these resource files in a Smarty template, a new {resources} function has been created. It can be called without parameters (to render links to all the assigned resource files), or it can be passed JavaScript or css file paths... if you really want to:

<html>
  <head>
    <title>Test</title>
    {resources}
    {resources js=$myJsFiles}
    {resources css=$myCssFiles js='path/to/another-js-file.js'}
  </head>
</html>

Uniqueness is enforced for all included js and css files. Because all js and css includes go through these two methods, files can be aggregated and compressed before delivering them to the user, resulting in huge efficiency gains.

Template regions

View 2.0 adds the concept of regions to Zoop templates. Regions are areas of an html page, such as headers, sidebars, and footers. By using regions, a developer can easily assign common templates or code at the application level, at the zone level, or at the page level.

The default regions are currently 'header', 'sidebar', 'content' and 'footer'. Each of these regions come with a default template, but region templates can be changed for different sections of the app, and regions can even be added or removed at the zone or page level.

For example, site-wide header and footer templates might be defined at the application level via a config file:

zoop:
    gui:
        templates:
            header: my-style/header.tpl
            header: shared/footer.tpl

While a sidebar menu might be defined on a zone-by-zone basis:

function initZone() {
    $this->assignSidebarTemplate('my-style/admin-sidebar.tpl');
}

Content can even be assigned to the default regions without adding any template files whatsoever:

function pageFoo() {
    global $gui;
    $gui->assignHeader('<h1>This is the "header" region.</h1>');
    $gui->assignContent('<h2>This is the "content" region.</h2>');
    $gui->generate();
}

Rendering regions

The $gui->display() function will continue to display a single template file. The $gui->generate() function has improved a ton, however. If passed no parameters, it will generate the full site (base template and all regions) as defined by default or assigned templates. If passed a single template file name, it will render that file and insert it into the primary content region of the page:

function pageBar() {
    global $gui;
    $gui->assign('message', 'this is a test message');
    $gui->generate('base/message.tpl');
}

Note that the rest of the page (everything outside the primary content region) will still be rendered as defined by site default configs or any app, zone and page specific overrides.

Fine grained region control.

While View 2.0 ships with a sane set of default regions, they will not be ideal for everyone. Regions can be redefined at the application level config file:

zoop:
    gui:
        regions:
            - header
            - sidebar_left
            - sidebar_right
            - primary
            - secondary
            - footer
        primary_region: primary
 
        templates:
            header: base/header.tpl
            sidebar_left: mystyle/sidebar-left.tpl
            sidebar_right: mystyle/sidebar-left.tpl
            primary: base/content.tpl
            secondary: mystyle/secondary.tpl
            footer: base/footer.tpl

Of course, regions can be added, removed, or reordered at will, on a zone, subzone or page level:

function initZone() {
    global $gui;
    $gui->removeRegion('sidebar_left');
    $gui->addRegion('foo');
    $gui->addRegion('bar');
    $gui->sortRegions('header,foo,bar,sidebar_right,primary,secondary,footer');
 
    // (note that region sort order can also be specified as an array)
    // $gui->sortRegions(array('foo', 'bar', 'baz'));
}

Mas EJEMPLOS example

Publicar mas ejemplos de las aplicaciones de zoop
me refiero a ejemplo con bases de datos
plantillas TPL ejemplos variados con css diferentes
publiquen sus ejemplos o trabajos pequeños que realizaron

Coloque video tutoriales de sus experiencias de zoop