I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!
Related
When do you think is best to to use a mobile App Maker (Ex: Appery.io) and when to code using a framework (Ex: Ionic)?
Of course, that coding with a framework doesn't tie you to any App Maker label... But, besides that, any other matter I should consider.
I need to start a simple project that querys a some REST API and have some doubts.
So I thought about posting here to open my head to someone who has walked this road before.
I don't mean this to be an open ended question on what is the best framework and comparing them all. I am just trying to establish is it really necessary to go down the heavier more complicated frameworks or can I get a mature long term solution using something like Appery?
Thanks!
When it comes to mobile apps, and as in your case, apps that load dynamic data from server, it is usually better to go for mobile app frameworks rather than, for online app builders. There can be multiple reasons for this :
App builders usually come with a lot of features, but they almost always fail for some Custom client requirements.
They usually tend to cater the need for static apps, when it comes to dynamic apps that have a lot of data manipulation stuff, you should prefer your own framework and logic to do so..
You can almost everytime modify / tweak a framework, You can't do so with an appbuilder.
You aren't sharing your code on cloud [Matters if you are working for some critical organization / client].
You have total control over your code / view. You can tweak it, twist it and almost guarantee total ownership. All you are bound to is the limitation your framework imposes.
You can mix and match frameworks, that doesn't applies for an appbuilder.
These are some of my quick thoughts, there can be [and are] many more reasons for switching towards a mobile framework..
AppMakers are generally there as tools for Rapid Prototyping. These days they market that you can make production apps using Appmakers but when you start using them you will notice that one or some other requirement you have cannot be implemented. In my experience, app development time seems to be less for AppMakers but it is generally more. On the other hand Mobile App Frameworks provide a lot of flexibility and code reusability too.
I'm trying to develop a hybrid app which will deliver a range of simple teaching material to the user. I am planning on using Telerik App Builder in conjunction with Cordoba 3 to create the app. What I cannot decide is how best to package the actual content into the application. I'd like to achieve a separation of the content from the code, and just combine the two when building the delivery packages. (The content is being prepared by a subject matter expert.)
Is there a way I can use Cordova or Telerik AppBuilder to pre-populate a SQLite database as part of the app install process? Or am going about this in completely the wrong way? I have been researching this in the Telerik documentation but without success so far. If someone could point me towards a suitable example or even the correct places in the Telerik or Cordova docs I'd be very grateful!
I recently ran a techie webinar on the topic. The main idea is that you need a centralized system to host this content and this system needs to expose some kind of a service layer that will feed content to your app. To me this seems like a very growing market opportunity, but feels kinda the same as the web 1.0 days where all of us were trying to figure out how to feed cotnent to websites and everybody was building their own CMS in a way.
Telerik Backend Services provides an editing interface, so it can fit some requirements, but it's not a publishing system, plus you may not want to pay developer licenses to your back-end users or provide them with access. The premise of the webinar I am talking about was that we discussed how to integrate with another telerik product - Sitefinity to do this job for you instead. The first 20-25 minutes are an overview of the platfrom, so if you have seen it already, you can certainly jump to ~;0:25 to see the rest
http://www.sitefinity.com/campaigns/webinars/build-content-driven-mobile-apps
Now certainly it doesn't have to be Sitefinity or CMS for that matter, Sitefinity provides a bunch of App Builder related features that are handy, but you technically have a few options:
- Build your own applicaiton and back-end.
- Use any type of CMS or platform that will give your SMEs the back-end interface to publish and the service layer to expose to the app. In the webinar I also go through some neat tricks such as using push notifications upon publishing.
This way you get a clear separation of content and code - you can even get a separation of content structure and code, which is an idea i talk about in greater detail.
I hope this helps!
Svetla
I'm starting to build a rather big application in ExtJS Architect and I was wondering if it is advisable to split the application into multiple projects (to be precise projects as Architect defines a project)?
At the moment I am the only engineer working on this application, however more engineers may be assigned in the future. What would be the points to consider if you would to like to split up the project in smaller pieces or build one big project?
In addition: as far as I know it is not possible to 'share' a project in Architect over more than one developer. That votes in favor for splitting the project.
Disclaimer: I have not used Architect to build a project.
My thought on the matter is that if you are building an MVC project and you want Architect to manage your controllers and views you should keep all of it together. Especially if you have cross cutting communications between modules. However if you are 100% certain that your modules are completely standalone - meaning they have nothing to do with one another and might as well be separate apps ... (maybe they should?) ... then you could build them out separately and weave them back together after you are ready to ditch the architect. Remember its a one way street not an IDE. Bringing the modules together should just mean that the app.js now lists all of your controllers for all modules instead of just one for your module.
We are working on a Mind map based webapp as our final year college project. It will be a website where users will be able to create mind maps collaboratively. The user interface will be very similar to what https://bubbl.us/beta/ and hxxp://www.mindmeister.com/ have.
In a nutshell, the users will have access to whiteboard and drawing tools to create mind maps on a whiteboard. The changes made by one user will be visible to other session users. e.g. A session has three users A, B and C. If A changes mind map, it will be visible on whiteboards of B and C.
We were considering Flex, Openlaszlo few days ago but having limited time (about 3 months) for project completion, we binned those. For Flex we will have to learn Actionscript3 and for Openlaszlo there is no IDE support. So both of them won't be good choices.
We have shortlisted Silverlight and Vaadin frameworks as viable choices but we are confused as we don't have any experience with either of them. We need to take these points into consideration while selecting a framework:
Time frame for project - about 3 months, give or take 2-3 weeks
Learning curve for framework - should be easy (Very relative term indeed..In the context, we are familiar with VB6, PHP, Javascript and Core Java)
Necessary graphics related features supported - such as whiteboard, drag-drop widgets, animations(need not be fancy stuff) etc.
Availability of tutorials and good documentation
There are 2 open source mind mapping applications that can be useful for this webapp.
Silverlight - hxxp://silverdraw.codeplex.com/ (a webapp) - More like a POC design.
Java - hxxp://www.xmind.net/ (a desktop app) - Most of the mindmapping features we need are present. If we use Vaadin, we can re-use some code which is a huge plus point.
We are open to other suitable frameworks. Which framework would you choose?
P.S.: Excuse for obscure URLs'. New users are limited to only one hyperlink.
Disclaimer: I'm a member of the Vaadin Team, and do not know Silverlight very well.
I believe both Silverlight and Vaadin would be good candidates for your application, and for both the biggest challenge will be the client-side implementation of the visual mind-map component.
I took a quick look at XMind and it seems to be Swing based, so I'm afraid that the only way to re-use that would be to wrap the mapping component into an applet. You can easily do this with Vaadin, but it will require the Java plugin in the browser.
If you consider implementing the mindmap component without plugins, you have the following options:
Use the Vaadin core components (eg. the Tree, live example here) to visualize the mind map. Vaadin supports drag & drop, so this would be very fast to implement, and you would need to work with only server side Java stuff.
Create a HTML5 component with Vaadin integration for the mind-map. You can do this with the HTML5 canvas, and wrapping it in a Vaadin component is easy, but it'll require that you code the component with GWT. There are several examples on how to manipulate the canvas with Vaadin and GWT.
Create a SVG component with Vaadin integration for the mind-map. As far as I know SVG supports interactive stuff a little better than Canvas, and there are examples on how to interact with SVG using GWT and Vaadin. Note that the support for SVG is lacking especially with the older IE versions.
All of these options are feasible to implement within your timeframe (depending on what extra functionality you want). The first option is by far the easiest to do, but it might not be fancy enough for your requirements.
We have strived to make Vaadin as easy to learn and use as possible, and I daresay that our documentation is very good. In addition we have a very lively community filled with helpful experts. If you need more information on Vaadin just come over to our forums and we'll help you out.
You are kind off answering your own question. Use vaadin it will be a little extra work but then your saving huge amount of time on the mindmap coding.
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.