General question, what do you want from a web framework? - gwt

In a MVC application, what are some of the components that make up the application. What tools and functionality is missing that you would like to have. Regardless of the server-side language, what would you want?
I see a lot in my code where I code some much functionality that it seems should already be there. I looked at Google web toolkit and they seem to get it right. Widgets are widgets and you simply add them to your application.
For example. I work with J2EE apps but in other languages, the components are the same.
Controller Objects
Controller handlers, defined by methods in the controller objects.
Configuration files defining the URL mapping and settings.
Template server page files (e.g. JSP/ASP files).
Configuration files defining O/RM mapping between application objects and the database.
Configuration files defining the database connection properties.
JavaScript libraries (e.g. jQuery)
Logging configuration files
Resource message bundle files
Validation configuration files or code
Middleware components and objects (EJB configurations, JMS/Messaging configurations, etc).
Credit Card or other middleware connectivity APIs and libraries.
Anything else you can think of?

Built-in Unit Testing Component

I think one thing you're missing from that very exhaustive list is the automatic binding of request properties to form objects, and the saving of these objects to the session where appropriate. Form objects here being the object on the server that represents the current state of the HTML-based for displayed to the user.

I think scaffolding and automatic admin interfaces are very nice features too, that I dont want to miss ;)

You've made the assumption that all MVC applications are websites. MVC is widely used for more than just web apps so things like URL mappers, template server pages and "Server side" languages are not associated with the MVC pattern, so much as a particular implementation and adaptation of the MVC for use in web apps.

Related

RDF or OWL based Rapid Application Development Framework?

I am looking for an easy-to-implement solution for form-based ontology editing and I wonder if there are any active projects and which of them is the right path to follow.
I need to create instances of an ontology (lets call it ontology A) using forms (either web or desktop) and store them in a triple store (e.g. Virtuoso). I would like to hide as much details as possible regarding the ontological relationships between the entities defined in ontology A and provide a plain simple user interface for CRUD (Create-Retrieve-Update-Delete) operations based on the entity schema defined in ontology A.
For example, I have found two possible solutions in the protege ecosystem:
PropertyFormPortlet It is not a live feature in the current webprotege version.
facsimile project
As described in the respective paper this is a solution that has been implemented for a specific context. Therefore, adapting it to another domain would not be as straightforward as I would like.
I wonder, is there another solution (even out of the protege ecosystem) that could facilitate such a form-based ontology editing. Could somebody provide some guidance?
Just in case someone lands in this question, I write down my conclusions. Practically, none of which I tried worked, but still I found out some interesting things.
OpenLink Structured Data Editor:
OSDE is a browser plugin which aims at populating RDF graphs in the form of files, based on Linked Vocabularies. In my case it didn't work as my locally hosted ontology cannot play the role of a "Linked Vocabulary". However, OpenLink team said they will work on it.
OData2SPARQL:
In our test, the WebIDE did not manage to create the forms out of the box as suggested by the respective video tutorial. However, we managed to use OpenUI library as a client of the OData services automatically created by OData2SPARQL, providing a web service interface for our ontology.
Ontowiki:
In our test environment, OntoWiki partially worked. We could save data but there were some bugs when trying to add properties etc. OntoWiki developers said that they plan to refactor in order to actively support it in newer hosting settings, but this is not the case right now.

Handling element attributes based on user roles in GWT

I am trying to tackle a quite common scenario in GWT based application.
If user has role 'ROLE_A', then show him only 'Search' button. All the
other buttons will be disabled.
One way to address this is by calling an async service to get the user's roles and then handle the visibility/accessibility of different UI components.
Is there any generic way in GWT to address authorization? I referred to Handle Authorization in GWT application and Using GWT Generators for custom annotations but couldn't get whatever I need.
I'm using GWT 2.4.0 with Spring 3.0.5.
Any pointers would be much appreciated.
The way I do it (and I think how it should be done, really) is to include the roles into the HTML host page, rather than getting them through an additional request. Have a look at my dagger-guice-rf-activities archetype for an example (using Guice and Servlets security, but easily transposable to Spring)
Then on the client, use plain Java ifs to handle the UI. And for those big parts of the app that only some users will see/use, use code splitting so other users don't have to download too much code.

manipulating other modules functionality in zend framework 2

How can I manipulate other modules without editing them ? very the same thing that wordpress modules do .
They add functionality to core system without changing the core code and they work together like a charm.
I always wanted to know how to implement this in my own modular application
A long time ago I wrote the blog post "Use 3rd party modules in Zend Framework 2" specifically about extending Zend Framework 2 modules. The answer from Bez is technically correct, it could be a bit more specific about the framework.
Read the full post at https://juriansluiman.nl/article/117/use-3rd-party-modules-in-zend-framework-2, but it gives you a clue about:
Changing a route from a module (say, you want to have the url /account/login instead of /user/login)
Overriding a view script, so you can completely modify the page's rendering
Changing a form object, so you could add new form fields or mark some required field as not required anymore.
This is a long topic, but here is a short gist.
Extensibility in Zend Framework 2 heavily relies on the premise that components can be interchanged, added, and/or substituted.
Read up on SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Modules typically consists of objects working together as a well-oiled machinery, designed to accomplish one thing or a bunch of related things, whatever that may be. These objects are called services, and managed by the service locator/service manager.
A big part of making your module truly extensible is to expect your developers to extend a class or implement a certain interface, which the developer register as services. You should provide a mode of definition wherein the developers can specify which things he wants to substitute, and/or add their own services to -- and this is where the application configuration comes in.
Given the application configuration, you should construct your machinery a.k.a. module services according to options the developer has specified i.e., use the developer defined Foo\Bar\UserService service as the YourModule\UserServiceInterface within your module, etc. (This is usually delegated to service factories, which has the opportunity to read the application configuration, and constructs the appropriate object given a particular set of configuration values.)
EDIT:
To add, a lot can be accomplished by leveraging Zend's Zend\EventManager component. This allows you to give developers the freedom to hook and listen to certain operations of your module and act accordingly (See: http://en.wikipedia.org/wiki/Observer_pattern)

A good way to structure AngularJS client code with Play 2.1 as backend

I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ

DotNetNuke and custom development

We are considering purchasing DotNetNuke (or Sitefinity) on pretty short notice and there are is a question I have that I am having trouble finding a quick answer to. (I have a separate but similar post with Sitefinity as the focus, if you can answer that better or in addition.)
We are currently not using any CMS at all and we have some custom development that will not go away just because we go with a CMS for some or most of our site.
Our custom development is c# ASPX with Site Master and nested Site Master pages. These custom apps do not own their own top level in our web site, but are part of a branch, typically one or two levels down (for example, http:www.contoso.com/branch/app/default.aspx).
How is DotNetNuke typically configured in a CMS/Custom “mixed mode”? For example, is DotNetNuke installed at the “top” of the web site, or “where needed” down in the web site.
How does this relate when mixing CMS and custom web applications?
Does the CMS interface allow for adding these custom apps or do you just go to the web server and add them to the structure?
It appears from reading other posts, we can create our own custom c# modules and have CMS editors “drop in” the modules on the pages. Can someone confirm that for me?
If I did not provide enough detail, please feel free to ask for more.
DNN is most commonly installed at the root of the website, but that is not required. It is sometimes run as an application in a virtual directory that is part of a larger site.
It is possible to add .aspx pages at the correct location within the DNN. The UrlRewrite handler will initially look at all such requests, and assuming that existing pages, and friendly url handlers don't think they "own" the .aspx page, DNN will stop processing the request and hand it to your page. There is no specific way to "register" these pages with DNN. I wouldn't generally recommend this approach, but it does work and can make sense in specific situations.
Alternately, you can write your own DNN modules. Existing code, can usually be quite easily be adapted by converting the code to work in .ascx user control that inherits from PortalModuleBase. Code that wants to take advantage of core DNN features e.g. membership or permissions will of course need to be modified to use the DNN APIs.
The DNN module approach is generally the best option. But the details of your situation may make one of the other approaches more appropriate for you. Basically as long as your site is layed out so that it is clear which requests are destined for DNN and which are not, you can mix and match with other asp.net code as needed.
One thing that causes trouble in a mixed configuration is configuration inheritance.
If DNN is the root application, you'll either have to remove problematic http modules and handlers in the application's web.config or disable inheritance with a location setting in the DNN's (root) web.config:
<location path="." inheritInChildApplications="false">
<system.web>
...
</system.web>
</location>
Maintaining the inheritance between application's web.config and DNN web.config is fragile.
Changes in DNN web.config can cause the application in the virtual directory to fail. In addition to removing each http module and handler, you'll need at least to add DNN's App_Code directories to the application configuration.
On the other hand, location setting does not always play well with DNN modules, especially if they have aspx pages in addition to controls inheriting from PortalModuleBase. Personally, I've never got the location setting work well enough with DNN.
See also
How to disable web.config Inheritance for Child Applications in Subfolders in ASP.NET?
How do I stop web.config inheritance
Avoid web.config inheritance in child web application using inheritInChildApplications