Wact

[Resolution]

I told the creators of WACT (Web Application Component Toolkit)
that I would check out their porject when I got a chance and let them know what I think. I've just done a really close inspection and I got stuff to say!

I have some positive points and some questions: hopefully I can come to a greater understanding of what the final design objective is versus where things stand now.

Strengths:

• good use of accessors
• iterators!
• template style compatible with .NET
• a generally well thought out api - easy to understand
• good explaination of design patterns
• ambitious coding regimen! - ModelViewController, TemplateView, PageController, TransactionScript, RecordSet, LayerSupertype

Questions:

• What problem (set) prompted the creation of WACT?
• What solution or leading example does WACT provide in regard to other PHP projects?
• In regards to the PUSH and PULL methods you use to parse/present data; which do you forsee being the long term focus of WACT?
• When are you switching PHP 5?
• Will you eventually use PHP 5 DOM and XML fuctions to expand on current efforts?
• How does one aggregate views using the pull and push methods?
• How does security fit into the scope of WACT?
• How is template/application logic managed?
• Does WACT lead to high coupling in the MVC, why or whynot?
• What is the ultimate design objective of this project?

Last thoughts. PHP 4 just doesn't do this project justice, for example I run a 2500 barton core AMD with 500 megs of mem, Apache, PHP 4.3.3 - the simple examples we processing in around .10 - .14 seconds! A simple tag was taking that long, and at first I thought this just doesn;t play to the strengths of PHP - intersting - but it's just TOO slow.

Then I decided to load Turck cache and the time droped effectively by half to .06 - .08 seconds. I then got a wild idea to try PHP 5 beta 3 on the example as I was SHOCKED to find that the times dropped by 900 - 1000%! In other words those same simple tags were loading in .006 - .01 seconds AND it was without Turck caching in PHP 5. With Turck caching and I'm sure thre times would fall further.

What this means is that the program went from concept to a viable solution, speed is crutial because bringing the server to it's knees on a single request is not attractive - unless you read slashdot .

I want to now see this project in all the glory of PHP 5's new object model and perhaps even using some of it's principles like DOM, XML and Tokens to further refine development/implementation of WACT push/pull methology. Based on what i've seen so far the program looks less academic and more practical.

Things could get interesting, I'm curious to find out.


Thx for reading. I look forward to your responses.
Re-solution

[Selkirk]

Wow. Thanks for looking at WACT in such depth. This is very helpful.

What problem (set) prompted the creation of WACT?

WACT is based on the need to separate presentation logic and application logic (MVC), the need to perform advanced form processing, and the need to consolidate duplicate code. It has evolved from actual web applications that I have written, starting in May of 2000, when the first version of the form processing in WACT was written. Part of my original motivation for WACT was to be able to point to it and say "This is how I think one should do MVC in PHP" on these forums, where the topic comes up again and again. Since HarryF joined last spring and others later, the project scope has been broadening to cover more programming styles.

What solution or leading example does WACT provide in regard to other PHP projects?

Three of the four developers on the WACT project are using WACT for working commercial websites. The fourth may be as well. I do not have a list of software or sites running WACT. The project is young as of yet.

In regards to the PUSH and PULL methods you use to parse/present data; which do you forsee being the long term focus of WACT?

There will always be the capability to do both. There really is no more work that can be done to support the push model. Everything the push model needs already exists. There are several items in the feature requests tracker on the sourceforge project site to improve support for the pull model.

When are you switching PHP 5?

WACT is designed to run commercial web sites. When PHP 5 comes out of beta, we should be able to run under both 4 and 5. We welcome any testing or contributions toward PHP 5 compatibility prior to this. WACT will support PHP 4 as long as the sourceforge hosting does. WACT will likely support PHP 4 and 5 in parallel for some time after PHP 5 is released. (probably a year or more) It all depends on how fast the PHP hosting community switches from being predominately PHP 4 to predominately PHP 5.

Will you eventually use PHP 5 DOM and XML fuctions to expand on current efforts?

Probably not. The PHP based XML parsing cannot handle parsing of straight HTML very well. Most likely the XML_HTMLSax parser will continue to co-evolve with WACT. WACT is constructed so that parsing performance has little effect on application performance in normal circumstances.

How does one aggregate views using the pull and push methods?

Good question. Give me a concrete example, and I'll work out how to do it.

How does security fit into the scope of WACT

The form processing in WACT provides excellent support to prevent cross-scripting attacks. The form processing can accept any of the special characters ( < > & ' " \ $ ) and will treat them just like any other character.
In normal use, the database classes will store these special characters in the database as characters and be unaffected by SQL injection attacks. The database classes support a makeLiteral method which should be used when constructing SQL statements manually to prevent SQL injection attacks.
Once special characters are in the database, the template system does not currently provide any escaping of these characters when outputting to html (except in forms). This has to be done manually for now. Automatic default escaping of output variables (ala smarty) is high on our priority list for new features.

How is template/application logic managed?

Philosophically, we try to separate most of the logic into the PHP portion of the application and out of the template. Currently, we only have two tags that perform logical operations in the template: <DEFAULT> and <OPTIONAL>. The DEFAULT tag specifies a portion of the template to be output only when a specified template variable has no value. The OPTIONAL tag specifies a portion of the template to be output only when a variable has a value. (it is the exact opposite of DEFAULT)

This is an ongoing area of development.

Does WACT lead to high coupling in the MVC, why or whynot?

WACT is designed to promote a decoupled environment where components can be easily re-used, but not so decoupled that configuring and combining the components becomes overwhelming. Its a hard line to walk.

What is the ultimate design objective of this project?

To make it easier to write web applications in a commercial environment.

Last thoughts. PHP 4 just doesn't do this project justice, for example I run a 2500 barton core AMD with 500 megs of mem, Apache, PHP 4.3.3 - the simple examples we processing in around .10 - .14 seconds! A simple tag was taking that long, and at first I thought this just doesn;t play to the strengths of PHP - intersting - but it's just TOO slow.

The config file for the examples has the line in it:

[templates]
forcecompile = TRUE

This is a debugging/development statement. Remove it and the examples will run much much faster.

Then I decided to load Turck cache and the time droped effectively by half to .06 - .08 seconds. I then got a wild idea to try PHP 5 beta 3 on the example as I was SHOCKED to find that the times dropped by 900 - 1000%! In other words those same simple tags were loading in .006 - .01 seconds AND it was without Turck caching in PHP 5. With Turck caching and I'm sure thre times would fall further.

Impressive. I'd love to see what WACT under PHP 5 looks like in production mode, instead of development mode.

What this means is that the program went from concept to a viable solution, speed is crutial because bringing the server to it's knees on a single request is not attractive - unless you read slashdot .

WACT is designed with speed in mind. There are two benchmarks that are included in WACT. Here are the results of those benchmarks on my 300 Mhz G3 / 768 Mb RAM running PHP 4.33 and MySQL 4.1:

No caching:

WACT                        Requests per second:    12.45 [#/sec] (mean)

Smarty + Pear DB            Requests per second:    4.80 [#/sec] (mean)
Smarty + Adodb              Requests per second:    3.85 [#/sec] (mean)
PHPLIb + Pear DB            Requests per second:    5.34 [#/sec] (mean)
PHPLib + Adodb              Requests per second:    3.89 [#/sec] (mean)

no templates + Native SQL   Requests per second:    46.53 [#/sec] (mean)
PHPLib + Native SQL         Requests per second:    10.71 [#/sec] (mean)
Smarty + Native SQL         Requests per second:    10.46 [#/sec] (mean)

Page caching:

WACT                        Requests per second:    17.45 [#/sec] (mean)

Smarty + Native SQL         Requests per second:    8.18 [#/sec] (mean)

100% Native PHP uncached    Requests per second:    47.08 [#/sec] (mean)

A couple notes on these benchmarks: The "100% Native PHP uncached" and "no templates + Native SQL" cases are the same. The difference in times gives a good idea of the margin of error in timing (mostly due to a warmed up OS caching). One thing that is interesting to note is that for this simple example Smarty with page caching on is slower (8.18) than just re-calculating the page each time (10.46).

I would be thrilled to see the results of running these benchmarks under Turck cache. I would be thrilled if the benchmarks even worked under PHP 5.

I hope I've been able to answer your questions.

Also, a note on project status, we should be making a downloadable release in the next few days. We're just finishing up a couple of installation READMEs before the release.

[Resolution]

Thank you for your indepth response!

I did have a question though I'm still curious about:

• How does security fit into the scope of WACT?

Also, on thinking more after reading your response what I think attracts me the most to WACT is the tag style that is used. I like the ability to transform XHTML and also use WACT tags to encapsulate data to be transformed.

• What is next on your todo list for the project?
• What other tags and syntax will you all be using?
• How do you decide what ecomes a tag?
• How will WACT handle conditional loops?
• Will that be in the control file (php) or in the template itself? I think this is where many projects have trouble.

Last but not least I'm interested in how or what exactly WACT compiles into. I took a look at some compiled templates and it looks like a combination of seralized data and direct function calls.

• Would you elaborate on the compile process somewhat?
• Is the compile process what really speeds up WACt or is it a combination of somthing else?

Thank you, for the interesting dialog, look forward to your response.

Re-solution

[Selkirk]

How does security fit into the scope of WACT?

Does this answer your question?

What is next on your todo list for the project?

Add output filters to template engine
Add PullValues to template engine
Are probably the highest priority/highest visibility. There are alot of internal refactoring, bug fixes, etc. After that, there will be more work on the controllers. I think I have some cool ideas on that front

What other tags and syntax will you all be using?

There are a few new tags on the todo list:
<MIRROR>
<COLUMN>
<ALTERNATE>
<COMMENT>

How do you decide what ecomes a tag?

So far each tag has satisfied a need for one of the developers in the project. WACT is setup to allow third party tags to be used with WACT and distributed independently.

How will WACT handle conditional loops?
Will that be in the control file (php) or in the template itself? I think this is where many projects have trouble.

I would say it already does, in the control file (or template helper). Give me an example of what you want to do and I'll post an example of it from WACT.

Last but not least I'm interested in how or what exactly WACT compiles into. I took a look at some compiled templates and it looks like a combination of seralized data and direct function calls.
Would you elaborate on the compile process somewhat?

The parser breaks the input template file up into a stream of events based on XML/HTML syntax. The events are then interpreted into a compile time tree representation of the template. The compile time component tree is traversed to output a compiled template file. This step is almost like a serialization step except that nodes in the compile time tree need not have a 1:1 correspondence with nodes in the run time component tree. The compiled file is then read in at run time to create a runtime component tree for the template. There are two trees: runtime and compile time.

Other component architectures (such as ASP.NET) usually have one representation of the component which handles compilation, design, and configuration issues as well as run time issues. because standard PHP is not compiled, I chose to break this up for performance reasons at the expense of making it more difficult to write new tags.

The compiled template file can be considered a combination of a serialized tree and a partial traversal of that tree. It is my hope that this approach will give superior performance to the straight serialization approach, such as ASP.NET would use or the non-component approach, such as smarty uses. The WACT approach is a hybrid that sacrifices ease of tag development for performance. Tag use is unaffected.

Is the compile process what really speeds up WACt or is it a combination of somthing else?

That is part of it.
Another reason is that WACT has small classes with limited functionality. Thus, it doesn't load a lot of code you probably aren't using. Another reason is the PULL model in WACT avoids calculating values that may be used in the template when they aren't used in the template. The PULL model also avoid double iterating in lists, which is required for the push model and can save a bit of time.

sorry it took a while to reply.

[ghurtado]

Thanks for the insight, Selkirk. The more I learn about WACT, the more I like the design choices you and the team made.

[brainpipe]

Echo ghurtado. Nice job.

[ausurt]

Yes echoing ghurtados opionions i do feel the same way as him. The project has implemented very good Patterns and ones that come useful in a lot of situations.

I might give it a go, but im unsure at the moment. Right now relating to the thread i posted titled 'Classes' im just trying to find an easier way to load common classes and then will look at implementing various Design Patterns into my coding, also refering to Refactoring (Fowler) to help me create more efficient and effective code. But yes WACT does seem very good. Might toy with it when i get back home.

[Resolution]

Thank you for the great explaination again!

I see what you mean about the compiled templates, it's an interesting approach. When I get a bit more free time I'll delve into the process a bit more.

I'm curious though about the PULL methology and how it will work out in the grand scheme of things. Though pull has it's positives like selective load/execute and a more developer friendly view to interface with it just doesn't seem to hold up in other areas as well - opposed to the PUSH method you employ.

Take for instance earlier I asked :How does one aggregate views using the pull and push methods?

I'll leave out PUSH as it is PULL that puzzles me still in how it scales and functions within PHP.
Since all HTML is output upon process and HTML is processed top to bottom how then do you say add java script to a header in the 3rd nested view, where the 3rd nested view begins in the BODY tag?

This puzzle seems to get ugly for PULL. Though I could be incorrect, it seems PULL is well suited to smaller set of views as opposed to PUSH which is suited to a large set of views - per request.

PULL seems really elegant in how it only takes - system resources - what it needs, somewhat of a lazy load pattern but by doing this it seems to sacrafice flexability in the view layer.

Whereas PUSH loads all that it is given gaining flexability but sacrificing speed.

There's got to be a way to mix and match modes. I'm thinking..

Here is an interesting thought, what if a traditional PUSH "Model, Controller" and a PULL "View" where molded together somehow? That might yield a best of both worlds scenario - or at least a more favorable approach over a pure PULL or PUSH. Hmmm.. The hampster is now running in the cage..

If I can figure that puzzle out I would like to adopt WACT into my own project, as a hybrid of two styles. That would be interesting. What do you think about the PUSH and PULL method being used together?


Oh, Btw in regards to Add output filters to template engine - I thought mabey a small exercise I did using intercepting filters, could help expedite your design process. I know how hectic schedules can get. http://www.sitepointforums.com/showp...8&postcount=71
Feel free to comment on it's strengths and weaknesses. I plan on using that pattern!

Anyhow, this is a great project - WACT - I would like to help out if possible, that is if you and the team could use an extra pair of hemispheres. hehe...


Cheers,
Res

[Selkirk]

Take for instance earlier I asked :How does one aggregate views using the pull and push methods?

I don't know how to answer this question. It hasn't come up yet. Thats why I asked for a concrete example, to use it to develop a solution.

What do you think about the PUSH and PULL method being used together?

This is just fine. They are very interchangeable, although we are working to increase the use of the pull method in relation to the push method.

Anyhow, this is a great project - WACT - I would like to help out if possible, that is if you and the team could use an extra pair of hemispheres. hehe...

Absolutely. We are definately looking for help. How about developing an example of aggregate views

I would suggest joining the WACT development mailing list as a first step.

[Resolution]

Firstly, thank you for responding, the conversation has been interesting as WACT seems to be very convincing in terms of view solutions. Koodos.

Absolutely. We are definately looking for help. How about developing an example of aggregate views

Well, I have a working solution for PUSH modeling but the PULL doesn't seem possible - in HTML. Or it seems somewhat limited as PULL (WACT's model) doesn't buffer the output - that's the hangup I keep hiting. Without some sort of buffering - with php output buffering even - PULL seems crippled.

Anyhow, I will sign up for the mailing list - later.

Res