I have String like this:
{"response":{"count":997,"items":[{"id":2943,"first_name":"Vasya","last_name":"Babich","can_access_closed":true,"is_closed":false,"screen_name":"antanubis","track_code":"24fc13d6ZwhuhzyM9V1oRkohiruY-zXeoP1aliqA-1dA4qgxJrQAYSTQYe6kVWsTTKkXWWybQrHU"},{"id":231329886,"first_name":"Vasya","last_name":"Babich","can_access_closed":true,"is_closed":false,"screen_name":"lydka_lydka_lydka","track_code":"a348ab0aAo3CxaTAGsTDu4mpMdBMMjYxgAmOnr7PvUWgaanh141l5NGe_PlLz8a8unX1eOUxXj-GCo6esKk"}]}}
I want to show each value of "items" to user in browser and then user should be able to select one of them and save in database and in his own page in the website. I guess I should use loop and create html element for each item. But how to do this? What data type should I use to manipulate this data and store it?
Thymeleaf is the most widely used view/template engine with Spring Boot and can handle your loop requirement. Spring MVC enables you to manage your app behavior and define the data bound to HTML pages (views). You will need a database and there are lots of options. Check out Spring Data which makes it easy to work with all major database technologies.
Related
Is it possible to have 1 input text field that accepts characters from the user, and as the user types, queries to a webservice are launched, and to update the contents of another component dynamicaly with the results of the webservice (which would be a table below the input text)?
If you prefer to use Wicket form controls and Data Table component then you need to make the call to the REST service in your impl of IDataProvider.
Otherwise, as I explained to you earlier today in your other SO post you can do this directly in JS without Wicket. It is a matter of taste and skills.
For complex TYPO3 project using fluidcontent I'm looking for a tool, which show me the followering informations:
which FCE exists
how often and on what pages are they in use
which partials are used
which flux form fields are used (with name and type)
diposit some meta informations, e.g. tags, description ...
How would be the smartest way to implement this library in a typo3 project?
My idea is, to develop an extension which read the fluidcontent templates and show the informations in a frontend plugin with examples. But i have no idea to read out the information like "used partials" or "used flux form fields".
Any ideas?
Thanks.
FCE's are just cType elements in the tt_content table. you can write a simple query to count the different cTypes, thus gives you a list with all the used FCE's on your site. you can know on witch page they are used because every tt_content entry has a pageUId
for the flux fields. you will have to create a function that fetch all content elements that uses flux and then parse all the flexform fields. note that flux can also store data in other fields then flexform xml.
you can create a basic extbase plugin for this to show it in the front or backend
I have quite a complex class that has three one-to-many relationships and two many-to-many relationships with other classes. What I would like to do is to enable the user to fill all the details one by one - in one step or even better in multiple steps (wizard).
My class is called PeriodicTask - user has to select one Server object (which represents SQL Server instance ) and depending on the selection I need to present the user with the ability to select which databases he wants to use ( the best option would be to use checkboxes). I don't really know how to achieve this.
I would start with creating an action that returns JSON with databases for the selected server. It'll be invoked by jQuery. So far so good, but what to do then?
Should I add <input type="checkbox"> to the form for every database or maybe create another form and post to some other action? How to parse that when the form is submitted? Can I split it somehow into smaller steps ? HTTP is stateless so I somehow need to pass or remember the data that was previously submitted - how?
PS> I'm using Entity Framework here, so part of the class hierarchy is as follows:
You could do it like this:
User selects server instance from
dropdownlist.
After selection dropdownlist fires "change "event, handler of
which loads databases list to form using ajax (your action can provide JSON or html with checkboxes)
User selects checkboxes and presses
submit button
On submit you collect
checked item and post to action
using javascript
I would look at creating helpers for each of the options that would be self contained, they could maintain the state themselves.
Another cool option would be to create a tree view, where the root level is your server and next level is database. Load the data into a ViewModel so that it can be used as the data source for a tree view. It seems like a nice interface for what you have.
Believe it or not the Microsoft site is a great place to start when learning MVC
http://www.asp.net/mvc
I am working on a custom Joomla MVC component.
My view has a form where the user enters an ID. I have retrieved the ID ($input_id) in the controller. Now I need to query the database to get the name WHERE ID = $input_id, then write the name to a different database table.
Can this all be done within the controller or do I have to pass my variables to the model somehow? Not sure of the correct way to achieve this within the MVC framework.
All data and data manipulation should be done in the model (e.g. model your data). The controller is there to determine the path of execution and which methods should be called (e.g. the manager aka controller determines what needs to be done).
Have a look at this tutorial which will help you understand MVC for Joomla better by taking you through the development of a simple component.
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.