Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was wondering what kind of MVC pattern the illustration below is. We are developing a web application according to this pattern using ColdFusion and it goes pretty well so far. But is it even some kind of MVC at all?
A frontend page usually consists of:
- including the corresponding gateways (each model component has its own gateway with dedicated functionality)
- using the provided GATEWAY struct (contains components, arrays, structs etc. representing the desired data) to render output
- simple flow control (if/else/loops) to iterate through the provided data or distinguish view states
- if required: build forms (POST to same page) and name their field names according to GATEWAY specifications
The GATEWAY file (always separated from frontend page) validates the request (usually POST data) and takes care of the data retrieval (i.e. selects/inserts/updates on database). Usually the GATEWAY requests data regardless of actions (evaluation of runetime data like SESSION). All operations are fail-safe, so either there is data in the resulting struct or the data is empty. Either way, two arrays (success, errors) in the struct provide a log of all performed actions during the processing to react accordingly on the frontend page. Most data is provided as components (objects), but all in all it is not a fully object-orientied approach. The only thing they have in common is: they all describe input parameters (GET, POST, Session, Cookie) and outgoing parameters, like a (RESTful) web service.
I came up with a lot of ideas about the used pattern, but I wasn't able to match it in all regards yet.
To my mind the most important thing MVC provides is the separation between your view and your model. By doing this you can completely replace the view or the model without having to make changes to the other. In fact the main purpose of the controller is to act as the man in the middle between the two. Need to switch database servers, you shouldn't have to change out your view, or even your controller really. Need to create a new view, or replace the view you have, again you shouldn't have to mess with your model or controller really.
Ask yourself those questions about this proposed framework your going to create and the answers should come easy.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Firstly, the scenario in my question:
I want to deliver a form in bitesize stages, with the valid completion of one stage leading to the next until all stages are complete.
On completion, I'd like to use data once, and then forget it completely so I'm not holding on to any user data at all.
My options as I see it are:
Multiple views each with a unique form all bound to a single model. The final submit button in the chain triggers data in the model to be accessed, used and then that particular row removed.
Multiple views each with unbound forms, each adding data to a cookie, which is then read on the final submit, data used and the cookie deleted (either using sessions or plain old js hard coded into each template).
A single view and template containing a single unbound form, which progressively un-hides divs containing each stage until all stages are completed and final 'submit' posts data from the form, allows a view to process it and forgets it.
I can actualise all three of the above, but which is the most 'Djangonic' method, or is there a better method still?
There is a library made from the Django guys for this case: https://django-formtools.readthedocs.io/en/latest/wizard.html
It's not dynamic though, so when you click "proceed", it will render a new page. But you can probably write a javascript module, that can handle this. But I wouldn't go that far, it's a lot of work for little benefit. Just just django-form-tools and use the wizard you want and do whatever you need in the done stage of your view.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Thanks in advance! This is more a "philosophical" question then a direct request for opinions on code, though I would greatly appreciate anyone's input on code examples to look at.
I've been a "traditional" developer for as long as I can remember, and now I work professionally as a data scientist. That being said, the one frontier I've never truly touched is web development.
For a project I'm working on, I need to build (and in a somewhat expedited timeframe) a good-looking web application that functions somewhat similarly to a Wiki website (using existing codebases like Mediawiki is not an option here, so assume everything has to be built from the ground-up).
In trying to do things the "right way", I've set things up as follows:
Django models are built that seem to correctly capture the relational structure of data for the webapp, at least as tested by playing with Django's admin portal
Django is hooked up to a Postgres database
(1) and (2) are running inside Docker containers
The most important piece here left, obviously, is the frontend. I've tried to ask several friends and acquaintances for advice, and have been pointed in the Bootstrap direction.
From here, I admit, I'm a bit stuck.
I see examples on the Django docs that don't involve any Javascript (it seems, with minimal lift, HTML pages can directly interact with the database, using what seems like a pretty simple "insert-placeholder-here" logic, as I have set it up through the Django models). I see a similar construction here and here.
But then I see a whole other set of instruction on the web about how to make a functional webapp-- creating serializers for the Django models to JSON, building a REST api, writing the frontend page logic using Javascript and using a library imported into Javascript to interact with the manually-built API(s) to interact with the backend.
Now, of course, the "first" approach seems much simpler. The second feels like reinventing the wheel-- if I can simply use a construction like {{ num_books }}, why would I go about building all those APIs and worrying about JSON? But I feel confused. Is there a "right" choice, thinking long-term? It seems like I can find people using Bootstrap and other frameworks taking both approaches. Can I not use Javascript code unless I take the JSON/API approach? Does that even matter? What truly are the differences here?
A compass on the rough seas would be much appreciated. Surely I cannot be the first to try to build a functional webapp with Django... the frontend is totally foreign to me.
Thank you all!
In the first place, Django is a framework which means that it contains already a predefined set of necessary functionality that most people need, sometimes people say "with batteries included".
Before REST architecture was invented front-end and back-end were closely related to each other. There wasn't a straight line between them and it was hard to share business logic with other services.
Basically we can say that there are two options, how to organize front-end and back-end workflow with Django:
Using Django templates:
The most simple and easiest way to get started. All that you need already presented in Django. Let's take a look at this simple example:
views.py
def index(request):
fruits = Fruit.objects.all()
render(request, 'index.html', {'fruits': fruits})
And after that you can use variables from the context in your template like so:
index.html
<ul>
{% for fruit in fruits %}
<li>{{ fruit }}</li>
{% endfor %}
</ul>
Django template system is really powerful and customizable if the default template engine doesn't suit your needs there is a possibility to choose another one, for example Jinja.
You can do a lot of stuff there, but as a general recommendation, all the "computing" stuff shouldn't be stored on the template level because it can dramatically increase the time rendering of the page. The better place to put business logic is views and most of the work with the database on custom managers.
For dynamic parts of your application, you could use AJAX probably from JQuery library.
It's also quite simple to work with forms, Django by default handle it with csrf protection. Default validators and model forms give you real power.
When you use templates you depend on them, most likely you couldn't reuse your endpoints somewhere else and that's why you need REST. Django has a little set of features that can help you with it and most likely you would end up with django-rest-framework usage which one of the most popular libraries used with Django today.
Using REST architecture:
The example above would look like this, though there is ModelViewSet, which do the most of boilerplate stuff for you:
class FruitViewSet(viewsets.ViewSet):
def list(self, request, *args, **kwargs):
fruits = Fruit.objects.all()
ser = FruitSerializer(fruits, many=True)
if not ser.is_valid():
return Response({}, status=status.HTTP_400_BAD_REQUEST)
return Response(ser.data, status=status.HTTP_200_OK)
You can use ModelSerializer or write your own serializers. The validation process is simple and straightforward:
class FruitSerializer(serializers.ModelSerializer):
def validate(self, attrs):
# validate your data here
pass
class Meta:
model = Fruit
fields = '__all__'
To display this data on a web page you could use whatever you want, vanilla javascript or any javascript framework which supports REST, the most popular today: React, Angular, Vue.
With REST you could use the same API for your web, mobile application and so on. In the end, implement once use everywhere.
As soon as you want to have dynamic parts in your frontend, you will need Javascript at some point. To fasten up development I highly suggest to use a framework like Vue, React or Angular. They have dozens of tools to use for particular needs within your project. Also you might look into jQuery when using Javascript.
I am currently building a Django web application myself (started like 3 months ago). I use Javascript a lot to manipulate the Django rendered templates.
Why Django might be your right choice
The nice part about Django is the Model-View-Template architecture which by my opinion is an excellent framework for your wiki app. You request a http, Django fires the linked view-function and renderes the template - et voila!. And if you need data transmission from/to PostgreSQL you just build a model and include the data calls into the view-function to use the data on the frontend.
You won't have to build a user management system (built-in
django-admin)
You will have a lot of frontend required business logic included in the Django orbit
No need to worry about JSON. You just fetch the data from the database using python objects and work with that data in the frontend. If at some point json would be a better choice for whatever reason, you just manipulate it with a Python serializer.
It is pretty easy to deploy/publish a Django based application using e.g. digitalocean.com or heroku.com
Since this was some broad question, I hope I could provide you some hints on how to proceed with your development. However, feel free to comment this post for further questions.
To give you a brief feeling I will attach some snippets of my current project, using basic HTML, CSS and Javascript along with Django as the python based backend.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Qt/Qml uses model/view architecture Model/View Programming Model/View Tutorial but their examples are too simple. I want to know how it should look with more complex problem. Assume that we have Application. According to Qt's model/view architecture the best solution is to create ApplicationModel, ApplicationView and ApplicationDelegate. Now lets our Application to have a Console and other components. Console should be separated to ConsoleModel, ConsoleView and ConsoleDelegate. But Console has its own Input and Output, that should be separated to ConsoleOutputModel, ConsoleOutputView, ConsoleOutputDelegate and ConsoleInputModel, ConsoleInputView, ConsoleInputDelegate.
But how does it all should be combine? Should ApplicationModel contains ConsoleModel that contains ConsoleOutputModel and ConsoleInputModel? It makes sense, but what about views and delegates? Similarly or ApplicationDelegate should control ConsoleView and ConsoleDelegate? How then ConsoleOutputModel should be accesed by ConsoleOutputView?
I would be very grateful for every hint or example solution.
What you imply is mostly incorrect. There's no reason to nest models, unless you wish to logically combine their data - and if so, you'd need to write a custom proxy model to do so. Existing proxy models provided by Qt have only one source model. This is just what's there, doing a multi-source proxy is certainly possible.
In Qt's model-view model, a delegate has a specific meaning: it is the visual "skin" used to interact with the item. It specifically derives from the the QAbstractItemDelegate class. The delegate concept applies to the viewed items from the model, not to the view as a whole. You may need many delegates, not just one, or no delegates at all. It's not the same as the delegate concept from model-view-controller.
Another issue I see is with demanding that the entire application is an ApplicationView. Qt doesn't provide views that would construct a widget-based user interface of the entire application using the QAbstractItemModel as a data source. The closest you get is QUiLoader which can load an .ui XML file and instantiate the UI objects - but that does not use the model-view framework, and is a one-time action: any changes to the underlying XML model are not propagated automatically.
The way models and views are typically used in Qt is to couple a model to one or more view widgets. Those widgets then show some subset of the model (perhaps the full model) in a particular way. You can even couple a model to any widget's property using the QModelWidgetMapper.
Maybe this isn't the correct place to ask, but I asked this question on Joomla forums and did not get any answers. If someone can help me or at least point me in the right direction, I would really appreciate.
My question is: In a Joomla 2.5 website, I want to create two different kinds of forms for registering users. Maybe "registering" isn't the correct term. I want to create something like a very simple database which will hold records for two kinds of users:
- one which will be interested in working in projects, so in this case the form will have more fields and specific details to fill
- one which will be interested only in receiving newsletters from the site, and in this case only basic contact information will be required.
I did some research and found an extension named AcyMailing which can handle the newsletters for example, but I need to have all my potential users registered as Joomla users. I would like to avoid that if possible. If not, how can I differentiate the two kinds of users on registration, so the visitor can choose which option he wants and in this case, add more information to the registering process, if possible.
I'm not very experienced with Joomla, but since the site in question is already implemented using it, I don't have much choice.
Thanks in advance!
Chronoforms. Most definitely here would be a great use for their AWESOME free component. Your forms can work as registration forms (should you desire that); or can also just be free standing forms that log the information filled out on them to your database which you can later use however you would like (i.e. compiling a mailing list or something of that sort).
The form wizard makes it almost bullet proof, then you can have a form for 1 type of user to fill out, and a form for a different user build different ways.
That will get you the data - in order to mass mail those people you'll need a way to extract their emails out of the database (or find an email component that will let you email based on certain fields in the database or what have you); but it's totally possible and would be easily done I think with 1 simple mySQL query on your database table created by chronoforms.
In terms of something that will solve your issue quickly and get you the info you're looking for in two separate ways - chronoforms will do that exactly.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My Django site is an ecommerce store. Relatively nontechnical copy editors will be logging into the Django admin interface and writing the copy for each of the product pages. They have told me that they want to be able to create links in this copy to other pages on the site. For example, if a product references another product in its description, they want to link between the pages.
I see a couple of possible options:
They simply hardcode the urls in <a> tags in the copy. I've set up ckeditor for the admin textareas so this would be the simplest solution, but if the url structure of the site ever changed, (say we changed them for SEO purposes) all the links would break.
Introduce some sort of wiki syntax where they surround the text that they want the links to be in square brackets. Something like:
Widget A works really well with [[Widget B]]. It is good.
would produce:
Widget A works really well with Widget B. It is good.
Then you have the problem of what happens if the product's name changes?
Has anyone dealt with this problem before and come up with a solution that is flexible enough to allow changing links/names/etc?
I deal with this issue frequently. Ultimately, you have to be very persuasive to convince me to allow embedding links directly into the copy--especially with an e-commerce website.
What if the product name changes or is re-branded?
What if the product is discontinued... you don't want 404 errors from your internal links.
Do you really want to lead people away from your "add to cart" call to action that high up on the page?
Do they know your SEO strategy? Are they going to dilute your links? What verbiage will they use? Will they ensure the link is valid?
When I am asked to give copy/product development team the ability to add links I always start with a No. Ask them what they need them for, explain the problems that can arise (eg. extra cost in maintaining valid links, conversion rate considerations, SEO considerations), and offer alternative solutions.
For example, I usually offer the ability to allow them to associate products with products as "Associated Products", "Related Products", "Accessories", "More Information" etc. You can have these in tabs or lists at the bottom of the product page. These would be in models and thus you have control over not displaying discontinued products, the link names are the product names (which you have SEO control over), etc. Determine if they are going for cross-selling, up-selling, or providing the end user with more information.
As a last resort I have also used a custom code parser which is again based on the target object and not a hard-coded link. For example, let's say you give them the ability to do:
Widget A works really well with [product=123].
A custom template tag, parser in your model/view can replace that with a link to the the Product with id=123 (or use slug) based on get_absolute_url(). If the product is discontinued, the name can still show but no link. This only works if you have a policy of never deleting records. Even then, you may have to have some error handling for when they enter an invalid product ID or somebody does delete that product. That will happen.