Day 4 - FINAL KEYNOTE!!!!!

This is the final keynote.... OHNOEZ!!!!!!!!!

Even though I've ragged on it, it's been a good experience... Met a few of the people that are devoted to Zend, ZF, PHP, and those that are heavily part of the IRC Channel (#zftalk)...

So Mark de Visser just stepped on stage, to talk about the conference.
650-700 people showed up, which was an increase from last year.
25% of people came from outside of the U.S.
60 Sessions, not counting UnCons!!!!!

The PHP elephant showcased.

Showing us pictures from throughout the conference. Most of which are actually pretty funny.

Joking about how presenters are dressing up (finally).

Shoutout to PHP women! (Matt says, "WHOOO... Women!")

There's a bunch of talk about video, and how it's impacting the internet. How people share, how people dedicate sites to the types of videos being shared.

Day 4 - Session 1 - PHP, JS, AIR, et al

This is our last day at ZendCon, and you can tell the buzz has died down QUITE a bit.


PHP vs JS

• JS is a functional language, the functions are objects.
• Anonymous functions
• Define functions inside functions
• Object model is different, using the prototype model.
• Everything in JS is an object.
• Arrays are not associative.
• No include/require statements
• Event driven model/asynchronous actions.

Communicate via JSON to JS (jQuery).

Day 3 - Session 6 - Caching and Scaling

I'm late to this session... We opted to stop and talk with Katie w/Zend Technologies. No news there.

Ok so we walk in, and this guy's talking about caching - most of which is real obvious.

Right now he's talking about Memcached server farms.

Real quick, I'm going to interject my own thoughts on cache:

• Do NOT cache entire objects that contain sub objects. You should cache each object independantly.
• As objects need common sub-objects, you find that your cache is used more often.
• It is very important to clear your cached object when it is updated. One problem I've often hit is when the DB/external (read as NON-PHP) scripts update records, it's usually met with dismay to have to clear the cache.. I'm not sure why yet, but that's pretty common.
• This one is critical...... ONLY CACHE SOMETHING YOU'RE WILLING TO LOSE!!! As expected, something will creep up and cause issues (failures, bugs in caching schemas, etc).

So this guy's saying one important thing to consider is Failover protection. If (when) it fails, you need to have a failover protection in order to not overload your remaining servers. Dynamic allocation might be hard, but it's nice to be able to change them based on real tests.

Day 3 - Session 5 - Zend_Form

OK, You'll probably (or not) notice I skipped Session 4... I was actually present during it, but mentally it wasn't challenging or really anything worth noting.

Matthew Weier O'Phinney is giving a speech on Zend_Form, and if we're lucky Zend_Layout.

DOH! We're NOT lucky apparently.

LOL, and NO talk about Dojo.

The Problem (and the solution):
The downsides (problems):

• A form is HTML markup, with input filtering (sanitization and validation), error reporting.
• Even though forms can look simple, the markup isn't really all that simple.
• You also have to do your own validation, and other logic that mucks up your code. Not to mention it's not standardized.
  
• Even though ZF has validators and filter chains, it's still a lot of work.
• Your tests are specific to the input [types].
• Repetition of code.
  

The upsides (you guessed it, solutions):

• Enter Zend_Form.
• Completely configurable!
• Multiple filters
• Multiple Validators
• Required
• Labels
• Pass the form right to the view, and echo the object for the entire form (say it with me, "One Line of Code").
• Automatic errors for validation and required elements.
• i18n is easy to localize!!!
• Decorators!
• Break forms into logical groups.

Base classes:

• Forms
• Elements
• Display Groups
• Sub Forms

Plugins:

• Filters
• Validators
• Decorators
• Elements; you can create custom elements (like a calendar element or something)

Zend_Form_Element:
These store and manipulate element metadata, validator chains, filter chains, and decorators.
There are tons of element types for your typical form-based input types (i.e., checkbox, captcha, select, etc).
Elements are plugins, and loaded by Zend_Form AS plugins, so you can overload their functionality.

But makes an element?

• Metadata - stored as properties of the element, via overloading; anything that can qualify an element. Typically, it's used for rendering, such as with CSS classes or JS events, explicit IDs, or any other HTML attributes.
• Filters - normalizing input prior to validation (such as proper casing, etc). They attach to elements using addFilter[s](), setFilters(). You can even use Zend_Form::setElementFilters() to filter all elements.
• Validators - much like Filters, but (obviously) validate.
• Decorators - ditto of Validators

Another cool thing about elements, is you can specify order format. The default action is to set the order based on how it's added to the form.

Zend_Form_DisplayGroup:
These are for visually grouping elements when rendering.

Zend_Form_SubForm:
This is for grouping items together LOGICALLY. Usually for validation purposes, but can also be used for display purposes if desired.

When to use them?

• Multi-page forms are a good example of why to use them.
• Dynamic forms as well (multiple records of the same type).

Plugins:
You can specify alternate class prefixes to load new plugins, or overload existing plugins.
Filter plugins allow you to normalize or filter input, which you create your own kinds of. Many already exist for Alpha, digits, StripTags, etc.
Validators as well are nice in the plugin section so that you can make sure the user input meets your input criteria, such as EmailAddress, StringLength, etc.

Decorators:
These are difficult to understand, but can be very powerful.
Each decorator decorates the content passed to it, and iteravely you get your finalized output.
Each decorator also has awareness of the element/form/etc. When building a decorator, you can pull pertinent info and de specific things you want.

• Callback - delegate to a specified [sic] valid PHP callback
  
• Description - render from getDescription()
  
• Errors - render from getMessages
  
• Fieldset - puts in a legend if necessary, and wraps in a fieldset
  
• FormElements - Iterate through elements, groups and subforms
• Form - wrap into an HTML form
  
• HtmlTag - wraps in specified HTML tag (default
  )
  
• Label - render from getLabel() (default
  )
  
• ViewHelper - render using a view helper
  
• ViewScript - render using a view script

-- Italicized decorators are default for elements.

Form validation:

• isValid() = validate entire form (except optional fields which can be empty)
• isValidPartial() - validate fields submitted
• getErrors() - return fields with errors
• getMessages() - return error messages

Personal Thoughts:
A lot of these elements work almost identical, considering they're all plugins to Zend_Form.
Good talk.. good talk...

Day 3 - Session 3 - Ajaxy Sites

So this is actually a keynote session, and it's not really dedicated to "AJAX" per-say.

In reality, this discussion is mostly about different technologies (Fluid, Google Gears, etc) that will allow you to tie into the OS for features (growls, badge updates [mac], etc) as well as being able to do background threaded JavaScript (which Chrome has embedded Gears, so the browser is starting to pick up this instead of using plugins).

It also discussed how HTML5 will be changing ways we start looking at application design, particularly in regards to the Canvas element, and how you can dynamically draw on the retained objects to do things like video games, quick response applications, etc, at extremely fast frame rates.

I can't even begin to touch all the topics (disregar the fact that we were about 30 minutes late to the session) that the speaker was discussing, but I have to say this was one of the more technical and advanced ideologies of the ZendCon I've seen thus far. It definitely worries me about my age-old saying of how "anyone that can type thinks they can develop" in that it means we're going to see way more advanced applications come out. Doesn't sound like a bad thing right? Well, not entirely, but I think what we'll be seeing is a lot of apps start showing up that would normally be simple to do in a desktop environment being attempted in these new technologies, which will in turn eat up your PC because these crap-devs don't know what they're doing. It definitely looks like these technologies are becoming more advanced, but not necesarially making development any easier. With the advent and injection of threading being a popular topic, and newer ideas coming about all the time, I think it will be interesting to see how the IT industry (particularly the development industry) will shape, and what it means for us current developers.

-Spaz

Day 3 - Session 2 - Zend_Layout

This is what's called an UnCon, which isn't an official topic for the ZendCon.

I've attended a few of these, and haven't blogged about them, but from my experience here at ZendCon 08, these are generally more technical, and really discuss what I was looking to hear. The level of complexity at these are more advanced and more to my level rather than a lightweight discussion around implementing solutions.

We're still waiting for the talk to start, but there are technical issues (which seems to be a reoccurring theme today).

Slides: http://www.speedyshare.com/424358692.html

What are layouts?

• Consistent, independent, and common components of HTML/etc output.

The problem:

• Generally you used something like Smarty, or some [sic] other hackish implementation.
• Always include header/footer/et al on each page.
• Changing the structure for a particular page caused a lot of issues for sub-pages.
• Attempts w/ZF were trying things like pre/postDispatch events.

The solution is the 2-step-view pattern via Zend_Layout!
Gives total control of view; turn off, change view, partials, etc.

Partials will allow you to modularize your views, and can be reused everywhere.

Use the View methods to capture title, scripts, style information for your Layouts.

---

Summary:
This was a pretty simple discussion, albeit presented extremely solidly.... I give it 2 thumbs up compared to the rest of the sessions I've attended this ZendCon.

Day 3 - Session 1 - Pick your Service

I'm feeling a bit under the weather today, so my Blog-fu might be a little weak today.


Starting off today, we're discussing Web Services, and how exactly they fit into your application.

Quick note, this speaker is horrible, and goes a million miles an hour without explaining anything, often going over 4-5 FULL slides within a matter of seconds. Sorry for the lack of in-depth descriptions and/or a stream of conciousness.

What is a web service?

• Automate communications between systems by removing the human element as much as possible.
• Exchange information that different systems need yet don't share the same platform.

HTTP Auth:

• Extension of the HTTP protocol used for ident auth (RFC 2617)
• Zend_Auth_Adapter_Http - Supports Basic and Digest.

Common Server Components:

• Zend_Server_Interface "enforces" the use of the SoapServer API on server classes.
• Zend_Server_Reflection extends the PHP5 Reflection API to add features used in introspection for gather/delivering API metadata to clients.
• Zend_Server_Abstract is likely to be deprecated.

Operations:

• POST generally used for Create, Update, Delete
• GET generally for Read.

--- I'm sorry, this guy moves too fast and mumbles, and I honestly don't have the capacity to keep up with him (as seemingly no one around me does either as they're all going "robble robble robble"). Sorry folks