I was going through this PDF (http://nethands.de/download/zenddispatch_en.pdf) that elaborates the detailed workflow of a Zend Framework request.
It seems very confusing to me and so was wondering if someone can be kind enough to list these step by step in simple terms to me?
Many thanks in advance
The steps are simply:
Routing
Dispatch
The PDF looks complicated because it is listing all the places you can hook into this process, along with all the objects that are affected by it. For example with a controller plugin you can write some code that will run just before the routing (routeStartup), and just after routing (routeShutdown). In the PDF you'll see these represented as the green box above and below the red 'Routing' box.
The diagram in the manual is perhaps a little clearer: http://framework.zend.com/manual/en/zend.controller.basics.html
Related
I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
I've been developing a web application in CakePHP 2.x that uses an Image cropping tool to manipulate an image. Currently it passes Ajax calls to handle the manipulation onto a function within the current Controller which then calls a Component which contains the main processing and functionality.
I'm currently going through and refactoring this section of the code and I was wondering if it's possible to directly call the Component from Ajax and whether or not it is a good idea or not as it would simplify a chunk of the code if possible.
Thoughts, opinions and tips are greatly appreciated. Thanks :)
I'm currently going through and refactoring this section of the code and I was wondering if it's possible to directly call the Component from Ajax and whether or not it is a good idea or not as it would simplify a chunk of the code if possible.
It's not a good idea because this is how components are thought to be used. A component is not thought to receive a request directly but to provide additional - reuseable functionality - to the controlller level in the MVC pattern.
Taken from the documentation:
Components are packages of logic that are shared between controllers. CakePHP comes with a fantastic set of core components you can use to aid in various common tasks. You can also create your own components. If you find yourself wanting to copy and paste things between controllers, you should consider creating your own component to contain the functionality. Creating components keeps controller code clean and allows you to reuse code between projects.
I'm currently working on a school project where we need to display database info in a web UI.
I have a YUI3 Datatable with built in client side pagination. Now I would like to implement server side pagination due to the massive amount of data I will have to work with.
Are there any good solid tutorials on how to implement server side pagination in YUI3?
I've already gone through the API and the YUI2 tutorials I've come across have features no longer supported in YUI3..
No, not that I can find.
I've used this paginator with great success. But the documentation that did exist seems to have vanished both from the github repo and from http://blunderalong.com/yui/gallery/datatable-paginator/paginator_examples.html where it used to live. It may be worth pinging the author a message about it.
Like barnyr, I've used Todd Smith's paginator with great success. I agree that the closest you can get to a tutorial is by perusing Todd's comments in the code.
When I pinged Todd with a fix for a resizing problem, he responded that he had stopped working on it. I guess it's up to us to figure it out now. Also, he seemed to believe that YUI must have either picked up his code from the gallery or developed an equivalent solution; neither seems to be the case right now.
It is sad that blunderalong is gone -- it had lots of goodies -- but I have Todd's server-side pagination example fossilised in my repo:
https://github.com/selkovjr/bfs/blob/master/mojits/Samples/binders/index.js
And here is the server-side model that provides the data for it:
https://github.com/selkovjr/bfs/blob/master/mojits/Samples/models/samples.server.js
It is a bigger pile than you're asking for (the binder code also has row selection and inline cell editing), but at least it has the example you're looking for, almost unchanged.
We are still using YUI 2 which is really good large amounts of data.
Try http://yui.github.io/yui2/docs/yui_2.9.0_full/examples/datatable/dt_dynamicdata.html
and it might be good to do SQL sort for heavy loads which is cheaper.
You can try following examples
http://jafl.github.io/yui-modules/querybuilder/ for complete datatable implementation
or http://jafl.github.io/yui-modules/paginator/ for different pagination samples.
I have implemented paginator successfully using this example.
I have a client with a content-heavy site built in CMS Made Simple. The redesign requires a mostly AJAX interface, and I think a frontend framework like Backbone or Angular would be the way to go.
I want to avoid moving off CMS Made Simple, though (client is used to that interface, it will be annoying to migrate all the data).
I think if I could find or create a RESTful api for CMS Made Simple, I'd solve my problem. But after searching around online, I only found CGSocialApp module, which seems to provide a limited API for things like user management. I've also looked into other AJAX solutions for CMS Made Simple, and there don't seem to be good modules for it.
If there is no ready-made solution for me, how complex would building a RESTful API module be? I haven't built a RESTFUL api in a PHP framework before.
Thanks for any guidance!
So, there is no easy answer for this question, as the CMSMS doesn't have a build-in RESTful API.
I would go for one of the two solutions:
1. Output the content as hand made json.
In CMSMS, you really have a lot of control on the templates. You could change the default templates to output json content instead of HTML content. The only issue is that the CMSMS will still send an http content-type header, that you can try to ignore in the JS part.
To access the menu, just remove it from the main template and create an empty page who output the {menu}with a custom template that also build json content.
That's the quick and dirty solution, but it should be very accessible in terms of doing it.
2. Create a dedicated module.
As far as I know, there are no modules that expose the CMSMS in RESTFul format, but a module is really very easy to build. Well, you can try to build it yourself, with the help of the community. It don't really solve the current problem, but it's a hint.
I hope it shed some light on the problem.
From http://en.wikipedia.org/wiki/AJAX, I get a fairly good grasp of what AJAX is. However, it looks like in order to learn it, I'd have to delve into multiple technologies at the same time to get any benefit out of it. So two questions:
What are resources that can help me understand/use AJAX?
What sort of website would benefit from AJAX?
If you aren't interested in the nitty gritty, you could use a higher-level library like JQuery or Prototype to create the underlying Javascript for you. The main benefit is a vastly more responsive user interface for web-based applications.
There are many libraries out there that can help you get benefit out of AJAX without learning about implementing callbacks, etc.
Are you using .NET? Look at http://ajax.asp.net. If you're not, then take a look at tools like qcodo for PHP, and learn about prototype.js, jquery, etc.
As far as websites that would benefit: Every web application ever. :) Anything you interact with by exchanging information, not just by clicking a link and reading an article.
Every website can benefit from AJAX, but in my opinion the biggest benefit to AJAX comes in data entry sections - forms basically. I have done entire sites where the front end - the part the user sees had almost no AJAX functionality in it. All the AJAX stuff was in the administration control panel for assisting in (correct!) data entry.
There is nothing worse than submitting a form and getting back an error, using AJAX you can pretty much prevent this for everything but file uploads.
I find it easiest to just stay away from all the frameworks and other helpers and just do basic Javascript. This not only lets you understand what's going on under the covers, it also lets you do it in the simplest way possible. There's really not much to it. User the JS XML DOM objects to create an xml document client side. Sent it to the server with XMLHTTPRequest, and then process the result, again using the JS XML DOM objects. Start with something simple. Just try sending one piece of information to the server, and getting a small piece of information back.
The Mozilla documentation is good. Sites that benefit from it the most are ones that behave almost like a desktop application and need high interactivity. You can usually improve usability on almost any site by using it, however.
Ajax should be thought of as a means to alter some content on a page without reloading the entire page.
So when do you need to do this? Really only when you have some user interactions or form information that you want to keep intact while you change some content on the page.