After reflection over Fat models and Skinny Controlers (i have adopted), my question goes to view.
It's logic that :
View read Rowset (Zend_Db_Table_Rowset), so object container, or an array of datas ?
View test with Zend_Auth if user connected and show connect or disconnect pictures, or controller test with Zend_Auth and say if user is connected (like a simple data).
View construct url to others controllers/Action, partially or totally without controller datas (plain Example : href="/users/delete/$id"), or view must create url with datas controller (ex : $urlFormat = "/users/delete/%s" and $id = x from controller, and view compose it ($id can be in array with most $id for example in list view, with links to action).
So, view has responsability to format datas, to html, or to xml, to be parsed. But where are borders responsabilities. If you have an article, i can read. Good documentation is very rare.
One more, sorry for my language, i don't write very goodly english. Thanks.
Here are the answers:
No. This should be done by the Controller which will pass the data to the view in a var(s)
No. The controller should do all the tests. The auth test is surely a part of these control
The vars/params should be tested by the controller and the url can be constructed by the view
I think you should read more about the MVC pattern (this is the pattern which has been implemented by the Zend Framework and many others). You can read about this pattern here or wherever you want.
I pretty much agree with Aurelio. However, as for documentation not being too widely available, I have to disagree. Have a look at the list below, which contain both web links and links to text references all about MVC:
Links:
MVC Pattern
Zend Framework + MVC
Zend Framework MVC Folders (ZendCasts)
Books
PHP Objects, Patterns and Practice 3rd Edition (Expert's Voice in Open Source)
Pro PHP: Patterns, Frameworks, Testing & More: Patterns, Frameworks, Testing and More
Aurelio's answered your questions I believe, but here's some extra information. The Controller determines what should happen and put look after retrieving of information from the model.
The view however, isn't concerned with where information comes from, but takes care of the formatting. It's not responsible for connecting to databases, caching records or reading configuration information. I don't mean to be condescending in what I've said and hope that it doesn't come across that way.
Related
The project is simple, and it has to do with formula 1 statistics. The UI looks a lot like a game menu. Going from "option" to "option" in the UI you end up in an "endpoint" page where the user can see the statistics of his like. It's tree structure where every "option" is a separate view on my project.
The user click "Race standings" to load a page. The user click a year on a form to see next page. The user click a race of that year then redirects to "race result" page. The logic for doing this is to create a nice UI so the user would like to spend time on the site and navigate through the pages.
I POST data from my view's forms to a controller's function. This function fetch the data from the database using my models and the post parameters, do the logic and return('thatView', compact('array' , 'array2', 'etc). php and javascript on the views manipulates the organized arrays fitting them into html. Arrays contains text data, for example array 1 could be the data of a race-result table.
The way my project is structure is very amateur. No patterns, no architecture, no anything good. Using directly the raceresult domain on the browser will result error. The needed parameters are missing as they cannot be set from the domain, it needs the previous page to post the data.
How could i structure my project better? What patterns could i use?
This is a basic overview you can follow:
App
-- Repositories
-- Services
Route > Controller > Service > Repository
Controller's method calls Service method. Here you put your business rules. If there as need of calling database, use repositories to do that.
It's clear for you?
A website I am currently developing with Neos / Flow includes a self-developed shop system implemented as a Flow Plugin. The products, variants and vouchers are kept as domain models.
Since the customer wants to provide their website in different languages I need to find a way to manage translations for the domain objects.
I cannot find a way which is baked into Neos/Flow so my first thought was to simply insert translation identifiers inside the translatable fields (description & stuff like that) which are then used inside the view with the translation viewhelper. This would work totally fine if the customer would not want to edit those fields by themselves.
My next idea was to just implement an extra field for each language-dimension and each translatable field (like description_en; description_es, …). But this would be the worst approach in terms of maintainability and changeability.
I usually worked on TYPO3 projects where translation of domain objects is really easy and working out of the box. So this experience inside Neos is very frustrating.
Does anybody came across a similar problem or even has found a solution to this?
whenever we've got the requirement to have multi-language content so far, we've solved that, by storing the data within the Neos Content Repository. This way language handling aka dimensions work out of the box. Also, building a UI for that records is very easy by using inline editing or the inspector of the content module.
Note, that storing data in the CR does not necessarily means, that you have to store it under the /site root node. You could also add a new root node /products to store your products.
You could have a look at https://github.com/neos/metadata-contentrepositoryadapter where meta data is stored under its own root.
Hope that helps,
Cheers, Daniel
For the record, something like that could also be achieved with the Doctrine Translateable extension in pure Flow:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
See http://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#on-the-doctrine-event-system on how to activate the extension in Flow.
However, the cleaner aproach indeed is to actually separate domain model and content (unless you build a CMS and the content is your domain ;)
I am having someone create a bunch of templates (themes) for a website, and want to keep data passed to the views flexible.
For example, with the users in the system I want to be able to supply the top x users and the most recent x users. In my controller I don't want to pass this data to the view, because he might just need the top 5 users and I am querying the top 10 - or worse, I might only get the top 5 and he wants the top 10.
I am thinking there would be two ways to do this.
1 - A view "helpers" file, which could contain functions like. getTopUsers($count) and getNewestUsers($count) which would do the model / repo call.
2 - Create a view presenter to keep these extra functions. I've had a look and there seems to be two main presenter packages - https://github.com/ShawnMcCool/laravel-auto-presenter and https://github.com/laracasts/Presenter
Maybe there is a better way?
There could be half a dozen of these, for various models...
I would pop some client side code into your views and access a route to a controller action (which returns JSON by default) and conditionally add that particular snippet into your view (via a variable passed to the view that determines if the person is logged in). Then you can apply an auth filter to your route to protect it.
Note: with this approach you can pass url parameters to your action. This means you can tell your controller to limit your results more easily.
This is a very interesting question, my friend. What I can think of is the following
1) cheap way, just query 10 or whichever the biggest number, and then pass a variable $count to the view or let view pass a variable to the sub view
2) api call, if you'd like to do AJAX call, then as others suggested, you could just design a new route, getData?count=5.
Normally it's not easy to meet all requirements, and practically speaking in the prototype stage, it'll be more cost-effective to write fixed function like getData5, and getData10, or just make two pages :) it'll be a lot faster than coming up another new architecture design and then realize in the end nobody really uses them.
I would develop my CakePHP application in the most reusable way. I'd like to treat it as webservices, so I don't want to strictly bind controller with view. My idea is: controller just returns json info, the view calls the controller and get the json and make html output.
How can I realize that? Could be a good approch, developing pages rather than views, and inside that pages call the webservices previously developed.
You can even forget about creating view files, using $this->set('_serialize', array('people')); in your PeopleController::show()
Well Cake is kinda' works like this "out of the box". You can use Router::parseExtensions(); to define what type of data you would like to serve. For example in app/Config/routes.php:
Router::parseExtensions('xml','json');
This will make it possible to detect what kind of request is incoming. For example if someone requests:
www.example.com/people/list.json or www.example.com/people/list.xml, in your PeopleController's list() method you'd be able to detect what kind of resource is being requested - json or xml, or of course any other
extension you define. This is what the RequestHandlerComponent is used for. You can check if it is xml for example:
if($this->RequestHandler->isXml()) {
//Some code
}
The different extensions are only different representation of the data, so it shouldn't matter what exactly you're serving. From v2.1 Cake will automatically switch the view class when it sees a JSON or XML request, which takes us to the new JSON and XML views.
All you will have to do is provide the views in the appropriate places.
In View/People (as for this example) you would have:
..View/People/
list.ctp
xml/
list.ctp - XML view
json/
list.ctp - JSON view
I'm looking for a strategy for managing links within articles. The body of the article is saved in a database and pulled during page assembly. What all should be saved in the database to easily define and manage links?
Some purists believe that markup should NEVER be stored in the database. Some believe its ok in moderation. But to me, the notion of a link is almost inseparable from its html markup.
Is there a better, more succinct way of representing a link in an article (in a database) than simply embedding "anchor text"?
One idea I've kicked around involves embedding just enough markup to semantically describe areas of interest, and in a different table, map those notions to actual URLs. All encounters of a particular notion get wrapped with the link.
<p>Here is an example of a
<span class="external-reference semantic-web">semantic</span>
approach to link management.</p>
A table then might associate the URL of the article and the key class of 'semantic-web' to a URL like http://en.wikipedia.org/wiki/Semantic_Web
<p>Here is an example of a <span class="external-reference semantic-web">
semantic</span>
approach to link management.</p>
Things I like about this approach is that all my URLs are in one location in the database. I could technically change or remove links without touching the body of the article. I have very good class names for CSS.
I don't like having another table to maintain, and another step/phase in render time. It could slow down response time.
Are there any other strategies out there that provide superior link management?
You may want to look at templating (such as Smarty for PHP).
I agree that markup shouldn't normally be held in the database.
However, you might also consider implementing a "pointer" concept, where at each link, you break your storage of the page, add a pointer in the table to the link, then a pointer in the link table to the next segment of content for the page. (I have no idea how complicated that would be - just an idea.)
Or look at how various CMS tools handle the idea. Some just put everything in the database as one big block of text, while others rely on templating, and others may do something else entirely (like object-oriented environments such as Plone).
There are a few attempts to do this that I have seen.
One way to do this is through URL redirects. You can implement a logic component on the server that will interpretate what the URL is requesting rather than a path to the content.
Another attempt is that the links orginally set to a reference value [which can be looked up in a database], and is requested at runtime/generation.
Regardless, you will have to reference the material that you wish to link to with some sort of identifier.