I recently started working with mason and hit upon the feature_brick which has saved me a lot of time, but there's something I quite don't understand about this feature structure.
The brick creates a feature folder with three main widgets: FeaturePage and FeatureView in view/feature_page.dart, and FeatureBody in widgets/feature_body.dart. I understand that FeaturePage is responsible of providing blocs with a BlocProvider widget, and FeatureView is where the UI is and where BlocBuilders should be at. But what about FeatureBody?
To me it seems like FeatureBody is doing the job of FeatureView, leaving the latter class mostly useless. Am I missing something here?
As far as I know, this separation between page and view is mostly for testing purposes. Is the separation between view and body helping in any way to this?
Feature folder structure
feature_page.dart content
feature_body.dart content
Related
I'm writing a Flutter app and planning to use GetX for state management (amongst other things). The common design pattern seems to be to use one dart file per view (screen) and for each view to have its own associated controller file.
However, what is the best approach when you have state that isn't just used within a single screen, but instead needs to be shared across screens? It seems wrong to import controllers from one view into the view or controller for another screen. Is there a better way?
Thanks
You can use GetxService: https://pub.flutter-io.cn/documentation/get_state_manager/latest/get_state_manager/GetxService-class.html
As it says: Unlike GetxController, which serves to control events on each of its pages, GetxService is not automatically disposed (nor can be removed with Get.delete()). It is ideal for situations where, once started, that service will remain in memory, such as Auth control for example. Only way to remove it is Get.reset().
Im currently working on a project where I want to the user to be able to chose between two layouts (list and grid) at runtime. I was searching for examples in the UI5 documentation (Sample Apps) and on GitHub, I did not find examples for how to to this or best practice examples. So I thought about how I could achieve this behaviour and had multiple ideas, but somehow none of them feels like doing this would be best practice.
Idea 1 - Destroy the "old" controls and generate the new controls inside the Controller
My first idea was to destory the controls I do not longer need. For example if the user wants to switch to the grid layout, the list and every control related it to it gets destoyed. In the controller the needed controls for the grid are created and then rendered in the view. In my eyes this would mix up view and controller logic inside the controller and does not feel like best practice
Idea 2 - Create two views and switch between them
My second idea was to create two views, each for the layout I need and switch between them. This would mean a lot of code replication in both the controller and the view. Does not feel like this would be the right way.
So I would be glad if you have own experience on this or if there is really something like a best practice for such a behaviour.
Thank you and kind regards!
I would say, idea 2 because of the following reasons:
It is best practice to work according to the MVC methodology which means separating logic, view and data. Since the controls define your view it is best to instantiate your controls in the files that are meant for it (the XML Views).
Performance: Destroying all controls means that if the user decides to switch between views, the controls have to be re-instantiated by the controller every time. This is, even though you probably won't notice it, not performant.
You don't need code replication: The argument of code replication is not necessarily true. If you can execute the same actions in the list and grid-view, it should be enough to just link the controller to both views and in that case you'll hardly have to replicate any code. Just make sure that you split your logic in enough functions. That way you might need to write some extra public functions to handle events, but not much more.
I want to implement navigating a tree structure like it is done in e.g. the WinRT file picker. I then want to be able to drop this behavior as part of any page.
My current attempt, is to try and register a secondary FrameAdapter/INavigationService in the container and use that for a frame that is different from the app root frame. So far, I could not get it to work.
My motivation behind that, is, that I do not want to reimplement sth. that the INavigationService already provides.
Basic structure:
ShellView that represents the general app layout (header, footer, navigation) and is currently an OneActive conductor.
Frame control (x:Name="ActiveItem") on the ShellView inside which the hierarchical navigation should occur
The chosen conductor has no relevance yet, since I'll probably have to nest the FrameControl inside another view later to really set up a MDI interface. I'll will want to have multiple screens that should be able to hierarchically navigate
I could not find a CM WP7 example of such a scenario
Can you help me out here?
My problems so far:
How do I access the container from a view code-behind without resorting to using the Application.Current. I figured, it is in the code-behind where I would want to setup the secondary FrameAdapter, since it is here that I have access to the FrameControl
How do I setup the INavigationService so that the initial loading by CM (populating the ActiveItem) is registered with it. There does not seem to be a navigation event for this initial display of the ActiveItem.
Many thanks in advance,
Tobias
PS: I have cross-posted to the Caliburn Micro discussions (Discussion over at CodePlex CM)
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.
I've been working with Zend Framework (using Doctrine as the ORM) for quite a while now, and done a few projects with it.
In a few upcoming projects I am requiring the need for widgets similar to how Wordpress does them. You have a post/page, which could look like:
Subscribe to my newsletter:
[subscribe/]
View my events
[events limit=5 sort=date/]
View this page's comments
[comments/]
Where say the subscribe widget would be replaced with Blog::subscribeWidget, and the events could be replaced with Events::eventsWidget, etc.
Now it has done my head in the past few weeks about how on earth do I do this??? I've come up with the following options:
I could place the widgets within controllers, and then call them like actions. Problem here is that code could be flying between controllers, and I have read this is expensive due to the amount of dispatches.
I could place the widgets as view helpers. So within the view I could have $this->renderPage($Page), which would then attend to all the widgets. Problem here is that what if the widgets need to do some business logic, like for example posting a new comment, that really shouldn't be within the view, should it?
The other option is to place widgets within the model? But then how on earth do they then render content for display?
Extra complications come when:
Say the comments widget would also handle posting, deleting of comments etc.
Say for the events listing, if I want to do an ajax request to the next page of events, using method #2 (view helpers) how would this work?
If I understand you correctly your widgets will need their own action controllers, which is where their logic for fetching data to be displayed, parsing form submissions, etc. should go. The difference between a widget and a page in this case is in how it's rendered, i.e. as an HTML fragment instead of as a whole page; you can use the Action View Helper to achieve this.
If your widget includes a form it should probably use AJAX to submit the form data back to the server, so that using the widget doesn't cause the user to accidentally navigate away from the page. You can inject the required JavaScript into the page you've included the widget into by using the Head Script Helper in your widget's view and/or action.
I left Richards reply, the problem, and further use cases cook in my brain for a while longer and ended up coming to a solution.
I will have the following view helpers and methods:
Content; with methods: render, renderWidgets, renderWidget, renderCommentsWidget (comments).
Event; with methods: renderEventsWidget (many events), renderEventWidget (one event)
Subscription; with methods: renderSubscribeWidget (subscription form).
I will have inside my configuration file:
app.widgets.comments.helper = content
app.widgets.subscribe.helper = subscription
app.widgets.events.helper = event
I will also have the following models:
Content for use for all pages.
Event for use for all events.
Subcriber for use for subscriptions to content
So inside my view I will do something like this:
echo $this->content()->render($this->Content)
Content::render() will then perform any content rendering and then perform rendering of the widgets by passing along to Content::renderWidgets(). Here we will use the configuration of app.widgets to link together the widget bbcode tag to it's appropriate view helper (using the naming convention 'render'.ucfirst($tag).'Widget'). So for example Content::renderCommentsWidget() would then proceed to render the comments.
Perhaps later on I will decide to have a Widget View Helper, and individual view helpers for each widget eg. ContentCommentsWidget View Helper. But for now that would just add additional unrequired complexity.
Now to answer the AJAX problem I mentioned. Say for the comments widget allowing for comments to be posted via ajax. It would simply have an appropriate method inside the Content Controller for it. So pretty much we also have a Event and Subscription controllers too - corresponding with the view helpers. Interaction between the view helper and controller will all be hard coded, there is no purpose for it to be soft coded.
I hope this helps someone else, and the current plan is to make the project where all this is used to be an open-source project. So maybe one day you can see it all in action.
Thanks.
Update:
You can find the source code of these ideas in action in the following repositories:
BalCMS - this is the actual CMS which contains the widgets in /application/modules/balcms/view/helpers and contains the configuration in /application/modules/config/application/balcms.yaml
BalPHP - this is the resource library which contains the widget view helper at /lib/Bal/View/Helper/Widget.php