Sorry this question is too broad, but I need any advice, because I'm facing a task bit above my experience level.
The map should be displayed with database objects like restaurants/events/etc. The suggested platform is Python/Django (which is fine both for me and customer) for both frontend and backend. As a map itself I want to use Leaflet because its (presumably) flexible and free. In the first phase there should be just one toolbar with checkboxes, allowing to choose object types to be shown on the map and time range to choose objects.
My draft is the following:
Leaflet (js based) as map
use database for map objects with default Django admin first and add functionality when needed;
use HTML and Django widgets for toolbar, checkboxes and all other stuff;
The only concern is about the frontend/widgets. Is it all likely to work this way? Maybe its definetly better to switch to JS frontend for this type of application (as future planning)?
Your plan seems solid.
Maybe its definetly better to switch to JS frontend for this type of application (as future planning)?
You're already using JS with leaflet, so I assume you're asking about building your own or using a maps service API directly. That approach will take more time, and will lock you into the service API, so I would recommend against it.
Related
I am very new to qgis and qgis server, which I have downloaded the plugins of Openlayers, and qgis2web with qgis 2.18. As an added note, I have a wordpress site which the map will go into. I have created a map with multiple layers. Hooked up database's data to it to populate what midwest state counties people had went to, who had went to those counties, and how many times they have been to that county. Even colored coded it to show case results. Now I am ready to put the map on the web. Here is my Question: How do you put the map on the web so it will show live data from our database we are using?
I have create a map using qgis2web and exporting it and then use place it within my wordpress's wamp server and was able to display it using an iframe. BUT, I assume it only created that one static instance of the map. If the datbase were to update, it will not show the correct mapping results. In so, I want to keep the map constantly connected to the database so it will show live data. How would I show live data and having the map constantly update? I think I have downloaded the qgis server as well, and hopefully set that up correctly. Was thinking of doing that way as well, but no luck. Any help where to start, or what to do is appreciated.
You might want to consider using Rethinkdb. It pushes JSON to your apps in real time. https://github.com/rethinkdb/rethinkdb
When you export a map using qgis2web it will export your layers as a static files. Using the latest version (2.22.0) it goes into the "data" folder and will create a .js file with the geographic information stored as a geojson (https://en.wikipedia.org/wiki/GeoJSON). Now for a feed with live data this will definitely not work.
To achieve a live feed there are a number of ways to build one. There are certain services like Qgis Cloud (https://qgiscloud.com/) or Carto (http://carto.com/) that allow you to do that. However, these service might not necessarily suit your needs. (In Carto's case only the base functionality is free of charge. The features for building a live feed cost.)
If you want to build it yourself I'm not aware of a "simple solution". There are quite a few different ways to build a web GIS. In short you'd need your geodatabase (like postgres with postgis), a map server software (like geoserver) that renders the geographic information in the database as WMS/WFS services that in return can be visualised using Openlayers, Leaflet or other javascript libraries. The resulting map can be implemented on your site (Some CMS come with plugins that ease the process of implementing mapping services. I don't know about wordpress though).
In any case, it is probably best to just refer to already existing answers and tutorials:
https://gis.stackexchange.com/questions/8113/how-to-start-web-mapping
How i could bind Spring DATA REST which outputs HAL, with ExtJS (v4.1) client, ExtJS do not have support for HAL, but how i could integrate libraries like Hyperagent.js or any JS library supporting HAL, with Extjs data model, to link Stores with the server through HAL.
Whats are the pros and cons of a such architecture ?
This is a very interesting question. There is not much information about how to connect ExtJs to a backend. I didn't find myself the information I was looking for when I started to develop a custom backend for an ajax proxy. I can only write from my limited experience a certainly biased answer, and I hope you will get other answers from different point of views.
I started with the idea to write a generic, standards compliant, client agnostic, RESTful API that exposes the tables in the database as they are. Finally, I ended up with a highly ExtJs specific backend, that implements many features that I perceive as they'd rather belong to the frontend.
What ExtJs imposes on the backend
ExtJs has a rigid relationship between the views and the stores. A view is bound to a store that is directly tied to a backend. That requires that the backend has to serve the data as it will be displayed in the grid. What really misses ( and this has been alleviated to some extent by ExtJs 5 ) is the ability to create a store out of the data of another store. This leads to an obligation to expose the data in a customized way related to the final view ( we already loose separation of concerns between the API and the application ).
This goes further when you want to use features like paging, remote filtering or sorting. If you have extensive data at some point you will have to because of performance issues. The way ExtJs sends the parameters for paging ( by the way this is enabled by default ), sorting and filtering looks peculiar to me, and I think this will require you to adapt your backend for ExtJs at this point. If you use filters alot, you will even need to configure them in the backend, because filter properties like starts with vs contains and case sensitivity make unfortunately not their way to the server. Again a presentation element more introduces itself into the backend.
ExtJs 4 has only a limited support for associations ( and it is not compatible with version 5 ). Advanced features of REST like the ones explained in the post linked by #Jaimie are not supported by ExtJs. ExtJs has a flat approach to REST, each table has its own endpoint. There is a way to send data from a linked table in a tree-like data structure, I wasn't able to get it work, but if you implement that you'll end up with another ExtJs specific feature in your backend.
My current approach
With all these requirements from ExtJs's side, I felt forced to write something really ExtJs specific. What I tried to avoid in the beginning is now the force of my backend : specificity.
I have a class that implements crud operations, paging, filtering and sorting for any mysql table, all secured with authentication. It does exactly what ExtJs expects it to do.
I can create a subclass for a table to allow finer grained control :
authorization using an ACL
serve a join or a view
extended validation before update or delete
custom filters
send notifications via a websocket for special actions
expose any data as a table ( e.g. list of files in a directory )
Conclusion
As you can see, the backend has very powerful features and is quite far from a mere data provider.
It is not an answer to your question about how to integrate a HAL REST api, but somehow it answers the pro and cons part : ExtJs has such specific requirements on its backend that without implementing them you would loose too much functionality. Modify the way ExtJs connects to the server could be an option, but I don't know to what extent you had to rewrite the code. It could require an important investment.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
The Single Page Application (SPA) has come to us. A lot of new things come with it as well, like Routing, Page life cycle at client side, MVC pattern, MVVM pattern, MV* pattern,... and some of Javascript patterns also come to us like AMD pattern, Singleton, Facade,..
A lot of SPA frameworks and libraries also were developed. We can find out some of its on the internet. They are AngularJs, Reactjs, BackboneJs, DurandalJs,.. and a lot of third party components to make the Javascript coding more easy like RequireJs, Amplifyjs, BreezeJs...
But I just think why do we need the SPA? Because it's seen to be introducing some of new complex things in developing the web application. Inspite of the SPA, we can use the traditional web application, each request each loading page. I just see a benefit like we can be easy to run it on the mobile and adapt with a new web application development trend. Could somebody explain more clearly about that?
One more thing, if we use a lot of third party components to composition just one SPA. So does it make a consistency for this web application? I think it should make a complex for maintain a huge components inside our web application. How do you think about that?
All suggestions are welcome.
I believe that this is the direction most websites should be moving in considering the number of devices that users utilize today, and the abilities and limitations of each.
IMPORTANT:
Before reading the rest of this, please understand that this concept is built on the foundation of basic principles of designing for the web. In order to design a single page application for all devices and situations, it cannot be run exclusively as a single page application. You must build a foundation that will work on the most basic of browsers with highly limited features and enhancing the user's experience according to their device's capabilities.
This may cause more work for you, but you will be capable of satisfying a larger and more diverse audience, which is much more impressive than throwing together a web app built only for modern desktop or phone browsers specifically.
Decrease load time and/or weight
Single page applications are more capable of decreasing load time of pages and the amount of data transfer from server to client.
Some of the most heavily impacting features of this method include :
storing any global functionality once it is loaded the first time,
allowing easier data transfer between pages and a more complex user interface
removing the cost of loading a whole page after a postback when you only need specific components
Increased chance of over complicating
This design method may allow for laziness in the developer and more interference from an end user. As a developer, be sure that your UI does it's job (get, display and submit to server) and that the server does it's job (provide, validate and submit to database). Most end users won't attempt to break your system using the information in a javascript file, but including information about your data structure is asking for trouble in my opinion.
Start with a strong architecture!
As with any webpage, the processing of data can be moved directly into service handlers instead of pages which could result in an architecture utilizing the following layers:
Database (Data Storage)
BL (Data Handling and Transport)
User Interface (Data Display and User Interaction)
Services over page handling
In my opinion using services is pretty much a requirement for organized and modulated code in a website. The standard get and post methods used in backwards compatible website can also use these services to hit services representing business objects instead of pages. This allows your code to be more generalized across modules concerning the same objects.
The update to a single page application then becomes simplistic in that you can initialize any UI to pick up the get or post methods and perform them using AJAX methods instead of causing a postback for events, thus a single page instance.
A side effect of using these services to handle UI events is that you eliminate the need for event handling in a code behind file except for life cycle events. The life cycle events are useful for handling and modifying relevant data to display based on the situation as well as modifying the returned html to lighten the load on the user's device.
Deferred Loading!
Any complex website will come with complex modules and plenty of unique components.
A benefit you gain from using a single page application is that you have the option to deffer the load time to an ajax process and do so whenever you like for any part of your application (i.e. first attempt to use a module, dead time after initial page load, etc), making the initial load faster and the processing time more controlled.
My list of best practices
As for best practices.. there are quite a few optimizations that could and should be made to a design intending to use this method, such as :
storing information as it comes, obliterating when no longer relevant
loading in script, html and js files through ajax only when needed
using data loaded on one page in another if it can be instead of reloading for each new "page"
minimalist data structure for the UI since it is a means for displaying and not for processing.
don't obsess with validation on the UI because your services should already be built to validate any information submitted to it
These optimizations are helpful with load time, data handling and object associations. Obviously this is not a complete list, but it is a great head start to building you single page application.
Finally, I would suggest researching concepts for designing for one web to help build a solid foundation. After that, the rest is relatively simple enhancements. (TIP: One of those enhancements is to catch all actions resulting in a postback and use the information to build a asynchronous call instead).
There is all sorts of information on this, and all sorts of libraries to use, but I would suggest using your own code as much as possible for the basic functionality and to get into the library code that solves your issues and do some research instead of trying to implement a complex system with generic library code. Using their code as an example may lead to a smaller overhead and stronger code for your specific situation.
Good Luck!
Currently, I am evaluating the creating of a map based system to plot data. This data would consists of shape layers (a grid - stored in a SQL 2008 Geography column) and multiple points (~5500 initially - Lat/Lon points in the same DB) that will plot the location of items on the grid. So, my question is - is there a large difference between the SilverLight Bing Map implementation and the JavaScript based implementation. Here is what I can gather from my research:
SilverLight Pros
Can handle large amounts of data more quickly
API/SDK to tie directly to .NET application code
JavaScript Pros
Do not have to download/install Silverlight on client side
Can leverage JQuery or other frameworks to pull data from webservice (I know SL can do this to using WCF, but I know JQuery rather well)
I know from this list that it looks like I should go with Silverlight, however I also have 'NEVER' done a bit of coding using the XAML stuff. Most of my experience as of late is the .NET MVC stuff and I cannot help but to take that into account as well. Does anyone know the performance 'ratio' between SilverLight and Javascript or at what point JavaScript implementation will choke? One more thing, I have looked at the DataConnect project on codeplex, but it seems to be broken - I cannot get the WKT or XAML functions to work either on their live site or the downloaded project.
If anyone out there has done a comparison/has words of wisdom for guidance/can add to my list for either of the two, I am all ears.
EDIT
I found a great Javascript/.NET MVC application example using SQL 2008 on CodePlex - Ajax Map Data Connector. It gives examples of pulling polygons, lines and points of interest from the database, placing them on the map using images tiles or the MS API as well as using intersection to determine items around a point or within a bounded box.
Personally I prefer the Javascript version because it's more multiplatform (e.g. mobiles) and easy to integrate in a webapp (plus I also love jQuery), but I think the deciding factor is probably what do you want to use the application for ?
However for Javascript, even if I love version 7, you may want to stick with version 6.3 for now because too many core components were removed (but are planned to be re-added in the future), e.g. infoboxes and client-side clustering (of course you can do your own implementations, that's what I did personally, but I would advise to use 6.3 for now).
I'd go with the javascript control (better support for multi-devices, is currently being more actively developed than the Silverlight control, sounds better suited to your skill set). However, don't try to plot 5,500 points on it. It will die.
What's more, if you're thinking about plotting 5,500 points then there's something wrong with your application design anyway - an end user is not going to be able to discern that many different points on the map. Let them filter for particular types of points, or only retrieve those that are visible in the current mapview, or use clustering to group up points at higher zoom levels - you should only be looking to have at most maybe 100 - 200 data visible data points on the map at any one time. If you really must plot that many points, then pre-render them as a tile layer and cache this rather than trying to plot dynamic vector data on the map.
And, I disagree with wildpeaks - v 7.0 is the latest stable release of the Bing Maps AJAX platform, and is a major change from v6.3. If you start coding with v6.3 now you'll only have to go through upheaval at a later date when you have to migrate to v7.0. Best to start off with v7.0 than learn a deprecated API.
Preamble
So, this question has already been answered, but as it was my first question for this project, I'm going to continue to reference it in other questions I ask for this project.
For anyone who came from another question, here is the basic idea: Create a web app that can make it much easier to create other web applications or websites. To do this, you would basically create a modular site with "widgets" and then combine them into the final display pages. Each widget would likely have its own set of functions combined in a Class if you use Prototype or .prototype.fn otherwise.
Currently
I am working on getting the basics down: editing CSS, creating user JavaScript functions and dynamically finding their names/inputs, and other critical technical aspects of the project. Soon I will create a rough timeline of the features I wish to create. Soon after I do this, I intent to create a Blog of sorts to keep everyone informed of the project's status.
Original Question
Hello all, I am currently trying to formalize an idea I have for a personal project (which may turn into a professional one later on). The concept is a reflective web application. In other words, a web application that can build other web applications and is actively used to build and improve itself. Think of it as sort of a webapp IDE for creating webapps.
So before I start explaining it further, my question to all of you is this: What do you think would be some of the hardest challenges along the way and where would be the best place to start?
Now let me try to explain some of the aspects of this concept briefly here. I want this application to be as close to a WYSIWYG as possible, in that you have a display area which shows all or part of the website as it would appear. You should be free to browse it to get to the areas you want to work on and use a JavaScript debugger/console to ask "what would happen if...?" questions.
I intend for the webapps to be built up via components. In other words, the result would be a very modular webapp so that you can tweak things on a small or large scale with a fair amount of ease (generally it should be better than hand coding everything in <insert editor of choice>).
Once the website/webapp is done, this webapp should be able to produce all the code necessary to install and run the created website/webapp (so CSS, JavaScript, PHP, and PHP installer for the database).
Here are the few major challenges I've come up with so far:
Changing CSS on the fly
Implementing reflection in JavaScript
Accurate and brief DOM tree viewer
Allowing users to choose JavaScript libraries (i.e. Prototype, jQuery, Dojo, extJS, etc.)
Any other comments and suggestions are also welcome.
Edit 1: I really like the idea of AppJet and I will check it out in detail when I get the time this weekend. However, my only concern is that this is supposed to create code that can go onto others webservers, so while AppJet might be a great way for me to develop this app more rapidly, I still think I will have to generate PHP code for my users to put on their servers.
Also, when I feel this is ready for beta testers, I will certainly release it for free for everyone on this site. But I was thinking that out of beta I should follow a scheme similar to that of git: Free for open source apps, costs money for private/proprietary apps.
Conceptually, you would be building widgets, a widget factory, and a factory making factory.
So, you would have to find all the different types of interactions that could be possible in making a widget, between widgets, within a factory, and between multiple widget making factories to get an idea.
Something to keep on top of how far would be too far to abstract?
**I think you would need to be able to abstract a few layers completely for the application space itself. Then you'd have to build some management tool for it all. **
- Presentation, Workflow and the Data tier.
Presentation: You are either receiving feedback, or putting in input. Usually as a result of clicking, or entering something. A simple example is making dynamic web forms in a database. What would you have to store in a database about where it comes/goes from? This would probably make up the presentation layer. This would probably be the best exercise to start with to get a feel for what you may need to go with.
Workflow: it would be wise to build a simple workflow engine. I built one modeled on Windows Workflow that I had up and running in 2 days. It could set the initial event that should be run, etc. From a designer perspective, I would imagine a visio type program to link these events. The events in the workflow would then drive the presentation tier.
Data: You would have to store the data about the application as much as the data in the application. So, form, event, data structures could possibly be done by storing xml docs depending on whether you need to work with any of the data in the forms or not. The data of the application could also be stored in empty xml templates that you fill in, or in actual tables. At that point you'd have to create a table creation routine that would maintain a table for an app to the spec. Google has something like this with their google DB online.
Hope that helps. Share what you end up coming up with.
Why use PHP?
Appjet does something really similar using 100% Javascript on the client and server side with rhino.
This makes it easier for programmers to use your service, and easier for you to deploy. In fact even their data storage technique uses Javascript (simple native objects), which is a really powerful idea.