In terms of modularization, it makes sense to separate the different parts of an application by creating and using frameworks.
So I tried to create a framework that shall encapsulate a set of SwiftUI views for a specific purpose. However, it seems that this does not work in terms of buildability and previewability.
Is it known if there are any restrictions on how SwiftUI can be used within a framework?
Assuming you're getting the following error as well?
NoBuildableEntriesError: active scheme does not build this file
It does indeed appear that previews won't work when the view file's within a framework, which is crazy; however, it is possible to include views after building them. I managed to make it work by:
Building the view within an App project, so I could use previews, etc.
When completed, moving it from the App to the Framework.
The resulting app will still build & run. I appreciate this is a ridiculous workaround, but at least it does mean that the views can be re-used without duplication.
Very much hoping Apple will address this soon!
Related
I'm building simple gis system on geodjango.
The app displays a set of maps and I'm also attempting to provide a RESTFUL API for these maps.
I'm facing a decision whether to create a separate app for the API or to work inside my existing app.
The two apps are logically separate but they share the same models.
So what is considered better?
Although a case can be made for either of the approaches, I think keeping the APIs inside their associated apps would be a better one. Since the code in APIs is going to depend on the models, or other utility methods anyway, keeping APIs in the same app would lead to more cohesive code. Besides the very ideology behind Django apps is that they can be isolated and reused.
There used to be a similar case with storing the templates. In the initial days of Django, people used to prefer to store all the templates altogether in the same global folder (with subdirectories by the names of the app), however, in recent times even Django has started discouraging the said approach in the favour of storing templates in the respective app itself.
#hspandher's answer is very solid and will allow for most of your needs to be implemented.
There is though another approach which may be a bit more complicated to achieve but gives you all the space you may need for experimentation and reusability potential:
Separate everything:
Backend:
Isolate your API from its visualization (see frontend below) and make it completely autonomous and self-contained.
That can be achieved by separating your apps inside your Django project and expose the corresponding APIs which must be the only way for an external factor (ex. client, another app etc.) to "talk" with any one of your apps.
Frontend:
Assuming that you have your APIs exposed, you effectively separated the visualization from the logic and therefore you have many options on how to visualize your maps.
For example, you can now build a React app which can make requests to your API and visualize the responses by using any of those tools: leaflet.js, D3.js, or anything that you like really.
Summary:
The benefits of this separation are:
Separation of logic and implementation.
Better maintainability.
Many tool and technology options to use.
Reusability.
As a side note, you can read about 12 factor method and think about using it in your implementation.
I am trying to move an application from using tornado templates (to be more accurate, it's jinja with an adapter) to ember.js.
It is my understanding that ember.js has very strong opinions on how to compose the final rendered product. In practice, it seems that the whole application must be generated from ember templates on the client side. The server side just provides data in REST format.
Is it possible to have ember work and take control only on some parts of a page that is mostly rendered by tornado templates (a la jquery plugins), or do I have to completely switch to ember?
Welcome, glad you're looking hard at Ember! You're right, Ember has definite opinions on how things should work :-) Despite that, it is indeed doable to migrate over in chunks.
You have a few options on how to handle this.
1. Build out from a single div on a page
You can see this in action on the builds page on the main Ember site (which is a small Ember app). Source for it is available here: https://github.com/ember-learn/builds/
Of interest is the fact that you can define the rootElement that you want Ember to render in to (see https://github.com/ember-learn/builds/blob/master/app/app.js although we should actually move that line to the config file). Once you have Ember on the page it is then possible to have it both interact with external Javascript or to have external Javascript call in as needed.
2. Sprinkle Ember components on to a page
If you need Ember to control multiple parts of the same page, you may want to look at https://github.com/mitchlloyd/ember-islands That addon is designed to work with server-rendered pages, so may not fit your setup. But it's another example of how to refactor in.
3. Use the new GlimmerJS (alpha)
You could also start refactoring into Ember using the newly announced GlimmerJS. The goal for this library is to allow folks to sprinkle in Ember and then as they need page routing and other aspects of Ember, allow them to switch over. So it may fit what you are after.
Note however that the GlimmerJS layer (on top of the Glimmer vm) is still quite new. What is there works well, but much of the Ember polish is still being added. So shipping to production could take some work ...
Let's say I'm writing a complex site in django with wikis, forums, ... or writing my own apps that I intend to reuse from different sites.
I really want to create, for example, a wiki page that has a forum at the bottom, or reuse my previously written wiki app with a different graphical layout.
What is the best way to structure my app to allow this kind of reuse?
So far, I have been giving apps their own urls in urls.py. This however does not work if I want to combine multiple apps together in a single page.
Additionally, most of the apps I found online come with their own templates, which has the full html, and do not separate the logic of creating / preparing a context from that of handling a request and generating a reply.
What is the best practice here? What do you do? edit the templates that come from applications you download online? refactor them to fit in your application?
what should I do for my own applications? structure them so they have a method to get the context, and a method to render it?
Django hasn't great support out of the box to component-oriented architectures. I find this problematic some times too. You'll face to problems here.
Architecture
Code
Architecture: As Django is not component oriented, all the apps aren't component oriented neither. The designers and coders for those apps haven't thought about that. So they've just built "views" to interface with their apps. You'll need to get something more "pluggable".
Code: Once you decide to build that, you'll have to find what support you have for that. Most Django apps are pretty well coded, so you won't have much code in views, but abstracted in other places. That way you could reuse that code and build your own components.
Example: Suppose you're working with a third-party Wiki app. That wiki has a view to display highest ranked Tags and other view to create a wiki entry. If the code is good enough (that I'm assuming it is because Django has a pretty good community), you could refactor that to use components. The view to create an entry must be using some Form, that you can plug in your own site. And the view to get highest ranked tags probably uses some utility function, or some Tag manager's method. In that case you could refactor it to your own needs.
Hope it helps.
For all the things I love about Grails I do have one small issue and this isn't really even a Grails specific problem. GSP changes require redeployments of the entire web application. I'm not talking about adding new dynamic data or major changes. These generally requires server side changes as well anyway.
But I'm talking about smaller changes like flipping the position of a couple of elements or modifying some simple static text on the page. So my question is, what are some patterns used or plugins, etc that allow minor changes to GSP's without redeploying the entire application? How can I make Grails template/GSP's more like templates and less requiring compiling?
I'm also possibly looking for something more designer friendly.
grails.gsp.view.dir, I think.
A trick to remember: add trailing slash and remember that grails-app/views will be added to it.
There is a Grails Plugin for using FreeMarker templates as views (I have not used this plugin myself). It is not listed as SpringSource supported, but I think the author is one the core grails devs and the plugin is based on a relatively new version of FreeMarker.
I have created a complex E-R diagram for a django site I'm developing. It maps to 11 tables in the database. The site has many features, so I would like to split it into multiple apps. The Django manual said that Django apps should be pluggable, but if I split the models into many apps, they would be dependant on each other. Is this a good practice? If not, how should I structure my application?
Thanks
I wouldn't worry over the statement about making apps pluggable. Sure, if it could be a useful app in other projects, you may want to - but nothing enforces this.
There is no harm in making internal apps dependent.
Personally, my project-specific apps live inside the project module (or for larger projects, inside a project.apps module). This way, you're not polluting the python import namespace with your one-time apps.
You could separate them out into self contained apps, and they would work within the context of your project.
You could also create each app so it's totally independent. This often takes a bit more work, a nice example of this is Django-tagging, which you can basically attach to any other object.
So yes, you can do it. However if the app is just for you it may not be worth the effort (IMHO) ;)