As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I need to make a CakePHP helper which involves making some HTML dynamically. But the part of the code is to make 1-2 database queries. These queries are very essential for this helper as all the text it populates is inside the database.
According to MVC pattern, i should not be making the DB queries in the View (Helper). I am wondering what the best design would be for this case as i want it to align with PHPUnit testing also.
Any ideas would be welcome...
Since the View job is purely to display the (already available) information passed to it from the Controller, I think it would be something like this:
Your controller:
public function foo() {
$bar = $this->MyModel->find('all');
$this->set(array('bar' => $bar));
}
Your view:
$result = $this->MyHelper->foo($bar);
You can create a component:
/**
* Set data info
* #access public
* #return void
*/
public function setData()
{
$data = $this->Model->find('first', $params);
$this->Controller->set('data', $data);
}
And print the helper in the layout:
echo $this->MyNewHelper->someHtml($data);
If it's something that could be an Element instead of a Helper, you can use CakePHP's RequestAction [details here] to pull the data needed for the Element.
You can then pass any parameters to the Element, and use those to pass to your controller, which does the model call.
This fits very well with MVC, as the Element only displays the view, but it specifies where it should get it's data (still using the model to retrieve it), which makes it very re-usable.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've looked around and haven't found anything specific to my question but that's partially because I'm unsure how to phrase it.
I manage around 20 different C# .NET applications that all do relatively similar things.
I am working on consolidating the common code into a data, business logic, and presentation.
My question is related to the Business Logic layer.
I gather that a business/domain object is one that holds state and sometimes may perform related actions (if you take that approach).
But what would you call an object that is only working through a routine?
For example:
In the presentation layer a button event is fired.
The presentation layer points to this class and calls the "RunJob()"
method.
RunJob() does all the work it needs to do and then finishes. For
example, it may read a table and output it into a CSV (a lot of
these apps are data pushers). It may or may not use internal
fields/properties. These properties may be used to display data in
the interface or to create output.
Is there a name for this or is it just a bad pattern/bad OO in practice? I don't think this qualifies as a business object or helper. I've seen some other topics that hint it might be a "Service" object.
Thanks!
call it WorkerThread for now and see uncle bob's article on naming" http://www.objectmentor.com/resources/articles/Naming.pdf. then change the name to something reasonable.
your class is not necessarily a bad class. most entities usually do not have much behaviour, otoh some helper classes do not have much state.
The name of your objects depend on specifically what work they do. TableImporter and CsvExporter are good names for the tasks you described. The methods should also be appropriately named. It may be the case that you want to abstract an interface Runner and have a generic RunJob method to decouple your presentation and model layers, but it could be more clear and decoupled if you use a controller instead.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to develop an application where the main Window would have a NSTabView with several NSTabViewItems, and in each item it will have a different NSTableView.
How would you organize the class architecture in order to be able to access from each tab tableview controller to the others? What is the best way to do it?
I have read a lot of stuff about passing data between controllers using delegates and so on, but I think there must be another clearer way to do address this problem.
Having the next example scenario:
TabOneController.h
#interface TabOneController : NSControl {
NSMutableArray *listOne;
...
}
TabTwoController.h
#interface TabTwoController : NSControl {
NSMutableArray *listTwo;
...
}
These two controllers implements NSTableView dataSource and delegate methods using its NSMutableArray list for it. I would like a proper scenario where both controllers could have access to each other (class methods, View Controller, another controller managing all or whatever a good idea would fit here). What do you think it is the best way for it?
Thanks in advance
If you want to share data between controllers, a good solution is to pass all controllers the same instance of the data object. If there’s more data to be shared or if there’s some extra functionality attached to the data, wrap it in a model class and let the controllers share a pointer to the same model.
If you want the controllers to call each other, there are many possibilities with different implications and there is no definitive answer, everything depends on the situation. The important question is: why would all the tab controllers want to access other tab controllers? Generally you should keep the controllers isolated. This is called loose coupling and it’s very good for your design.
If the controllers need to call each other, try to rethink the design. Maybe some of the behaviour should go to the model instead? For example, instead of calling another controller to delete an item from a list, you can move the deletion code to the model, and other interested controllers can learn about the model changes by observing the model.
Whatever you do, just don’t use singletons :) I have put some sample code on GitHub that shows how to wire a project without (mis)using singletons.
First option:
Declare instance variables for each controller that point to other controllers? For example, say you created a property anotherController in CustomController1 and:
CustomController1 *controller1 = [[CustomController1 alloc] init];
CustomController2 *controller2 = [[CustomController2 alloc] init];
controller1.anotherController = controller2;
This way, controller1 will have access to controller2. And then just do similar stuff to other controllers. You can even apply some inheritance there.
Second option:
From a particular controller do:
CustomController *customController =
(CustomController *)[self.tabBarController.viewControllers objectAtIndex:x]
Assuming CustomController is the class of the controller you want to access, and x is where it is located in the array that is maintained by the tab bar controller.
I would create a singleton class that will store data and handle all data operations...
You can store the data in the NSUserDefaults as the simplest practice.
If you are only going to be working with a few shared variables, I would just use the AppDelegate.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The following 2 methods are identical in terms of what they do. I wonder which of the following is preferred and why?
This looks cleaner from readability stand point, however i don't like the decks.playerDeck construct
-(void) playerMovedWithCard:(Card*) card {
[decks removeCard:card fromDeck:decks.playerDeck];
[decks addCard:card toDeck:decks.inplayDeck];
}
Definitely simpler, however the idea that card is removed or added seems to be lost (thinking of reader of the code)
-(void) playerMovedWithCard:(Card*) card {
[decks.playerDeck removeObject:card];
[decks.inplayDeck addObject:card];
}
I am leaning towards the first implementation, as in future the task of removeCard may be more involved then simply removing an object.
What do you think?
The first way is slightly easier to read, because your decks serves as a more meaningful object. However, passing decks.playerDeck and decks.inplayDeck is not ideal: removeFromInPlayDeck: and addToPlayerDeck: would be slightly better.
There is a definite advantage to the first way of doing it, though: you could add a moveCardFromDeck:toDeck: method to the class of your deck object, avoiding the need to pass the same card twice to two different methods.
It is better to even isolate the functionality of the decks object and remove any reference of decks.playerDeck and decks.inplayDeck from playerMovedWithCard. This way, you can change the class of decks without having to change any code in playerMovedWithCard.
For example:
- (void)playerMovedWithCard:(Card*)card
{
[decks moveToPlayerDeckTheCard:card];
// OR [decks moveToInPlayDeckTheCard:card];
}
This way, playerMovedWithCard is unaware of how cards are stored or even what happens when a card is moved.
You can change that according to what your app actually does, but the idea is to minimize any coupling between classes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Consider the following method:
+(void) myMethod:(int)arg1 **argument2**(int)arg2 **argument3**(int) arg3;
See how the first argument, unlike the 2nd and 3rd, doesn't have a description, giving it an impression of bad symmetry. Also you would expect the extra typing will provide named argument as you pass it in, but you still have to pass them in the correct order.
Can anyone help me make sense of this?
You're missing : after argument2 and argument3
Also, first argument is named myMethod. By Apple's naming recommendation guide, you'd see the method should be named in the manner that identifies semantics of first argument.
EDIT:
check out this document Coding Guidelines - Naming Methods
Hopefully the response to this other question will help you make sense of what you see.
The logic behind this exists though hard to get used to.
regarding your first note, about the naming of the first param,
Apple encourage you to name your methods as follows:
+(void)myMethodWithArg1:(int)arg1 Arg2:(int)arg2 Arg3:(int)arg3;
thus making the name readable like a sentence in english
(my method had Arg1 of type int, Arg2 of type int, etc)
regarding the named params and the inability to change the order, that makes no sence to me either
and the comment above me is correct, you are missing those annoying : after the params
In addition, the syntax of ObjC has strong relation to that of Smalltalk (http://www.smalltalk.org/main/)
I'd encourage you to read on that and the relation between the two languages
hope this helps
The method name is supposed to described the first argument.
Like:
+ (void)updateUserWithId:id andAge:age
So that the whole expression gives sort of a natural sentence.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It's well known fact that static variable cannot be used in
Web Application as it remains static through out application.But,is there any scenario where static variable can be used in Web Application to achieve the functionality?
Thanks
I'm not sure if I understand the question, but there are cases in which using a static variable in a web application is perfectly fine, if one understands the implications. For instance, a common usage in .NET web applications using NHibernate and the "session-per-request" model is to keep a static instance of an ISessionFactory around to create new NHibernate sessions. This is useful since session factories are very heavy objects and generally take a lot of resources to create.
You can store your static information in a number of places...
In a DB
In a cookie
In an Application or Session variable
In a querystring (or even a form variable)
(Or am I misunderstanding the question?)
configuration data, database connection strings, constant data for the application retrieved from a database source.
Anything that doesn't need to change after it's been initialized.
For example, I could get a configuration setting on a page and use if over and over again. In this example once myUrl is initialized it will never have to hit the web.config file again until the web application is restarted.
static public string myUrl = string.Empty
public void SomeRoutine()
{
if ( string.IsNullOrEmpty( myUrl ) )
myUrl = ConfigurationManager.AppSettings[ "myUrl" ].ToString();
...
Response.Redirect( myUrl );
}
You don't mention what web framework you are using, but if you are using ASP.Net, you can assign objects to the Application object or the Session object, which will hold information across the application between requests, and across all requests from an individual user respectively.
If you are asking in a general way, and I suspect you are as this is marked subjective+discussion, then you can try using a cookie to hold the variable across all requests for a user.
As for holding some value for all users, you should have a look at the web framework you are using. You have options such as storing something in a file that is accessible at each request, through to storing something in the equivalent of the Application object of ASP.Net.
I'm sorry if I'm being too pragmatic here, but it's late where I live :).