Considering adopting Yii - some high-level concept questions...

I've spent the last 6 months working quite successfully with CodeIgniter, but a few frustrations are making me consider alternatives. Particularly, form handling (especially validation) for complex pages with many buttons has turned into a coding headache. I also seem to spend too much time making basic functionality (authentication, form layout CSS etc) that could just be part of the framework.

I came across PRADO when reading about Delphi for PHP and ASP.net. I was initially very excited, but then I read about performance concerns (which I've definately seen on many ASP.net sites). My mind is full of questions:

  • Why can't you avoid the performance problems by storing view state information in a DB session table instead of as hidden page data? Are all web tools that attempt event-driven UI components doomed to suffering this problem?

  • Is Yii adopting MVC simply because of this or were there other problems? To what extent does Yii retain the concept of "fixing web statefulness" on behalf of the developer, and encapsulating all widget properties into a component? Or are MVC and event-driven models mutually exclusive?

  • In what way will Yii fix my coding headaches for complex forms - I want to work with input variables and rules, and have everything else taken care of (not coding low-level variables about error information).

  • I actually quite liked the idea of packaging all the relevant aspects of a UI widget (view state, properties, style, validators etc) into one component, rather than coding the same variables multiple times across the web stack. Is this is never going to be the best way on the web?

  • What's the quickest way right now to learn the Yii classes? I'm someone who learns best from examples rather than API specifications - will it help me to learn PRADO first while you're still working on the tutorials?

Keep up the great work!

Kind regards,

Mark

Quote

I came across PRADO when reading about Delphi for PHP and ASP.net. I was initially very excited, but then I read about performance concerns (which I've definately seen on many ASP.net sites). My mind is full of questions:

Quote

- Why can't you avoid the performance problems by storing view state information in a DB session table instead of as hidden page data? Are all web tools that attempt event-driven UI components doomed to suffering this problem?

Yes, in Prado you CAN use session to store view state information (there's

an application module that allows you to do this). However, this still doesn't

fully the performance issue, mainly because the whole page hierarchy needs

to be restored to handle every postback request.

Quote

- Is Yii adopting MVC simply because of this or were there other problems? To what extent does Yii retain the concept of "fixing web statefulness" on behalf of the developer, and encapsulating all widget properties into a component? Or are MVC and event-driven models mutually exclusive?

Yes, one of the main reasons for Yii is the aforementioned performance issue.

In Yii, we have stateful form concept, which allows you to (optionally)

maintain your page state without using session. See the included "hangman" demo.

Like Prado, Yii promotes component-based programming, which allows you to

develop, share and reuse self-contained components to quickly compose your

applications. A Yii widget is like a prado control, except that it is much

easier to create new widgets. I think MVC and event-driven are not mutually

exclusive. In fact, Yii has achieved certain degree of event-driven, but not

as much as Prado.

Quote

- In what way will Yii fix my coding headaches for complex forms - I want to work with input variables and rules, and have everything else taken care of (not coding low-level variables about error information).

Yes, this is well taken care of in Yii. For each form, you should create a

data model (either ActiveRecord or form model) to represent the data you want

to collect (you need this anyway). You then specify validation rules for

the model members. For the view part, you mainly need to specify the input

fields. Yii will take care of error display. For more details, you should

try the "first application" described in the Guide.

Quote

- I actually quite liked the idea of packaging all the relevant aspects of a UI widget (view state, properties, style, validators etc) into one component, rather than coding the same variables multiple times across the web stack. Is this is never going to be the best way on the web?

Yii widgets are proposed for this purpose. This is about software engineering

and should fit in Web programming as well.

Quote

- What's the quickest way right now to learn the Yii classes? I'm someone who learns best from examples rather than API specifications - will it help me to learn PRADO first while you're still working on the tutorials?

The Guide. Read "create first app" section and create your own one to start

having fun!

Many thanks for the quick reply. I'm impressed!

And is Yii going to become really event-driven like PRADO?

Nope, that's not the goal.

Is that because event-driven approach is ineffective from the performance point of view?

The term "event-driven" is a little vague indeed.

Yii has implemented event scheme, but this doesn't really mean it is completely event-driven. In order to be event-driven, the page needs to be stateful (like Prado does with viewstate). This is often inefficient for Web applications.