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 7 years ago.
Improve this question
I’m starting a new websphere commerce V7 Feature Pack 8 project from scratch.
Besides performance, my intention is to have a system that is easily maintainable for the future.
I’m not a big fan of dojo for lack of documentation, bloatedness, and complexity. Is it best practice to replace the dojo/dijit with jquery/requireJS/jquery ui? Or just stick with dojo?
Say I go with dojo, I’m not a fan of mixing libraries together. Could there be any conflicts or performance issues mixing jQuery and dojo together?
If you can mix both together, which one UI Library would you go with, dijit or jQuery ui? The websphere aurora wraps a lot of functionality around dijit, so I'm guessing dijit would be a first choice.
All advice would be appreciated!!!
This question is bound to be subjective, but I am compelled to address each of your points above:
While the full Dojo Toolkit source is large (mostly because of dojox), it doesn't have to be bloated - it's not as if you're forced to load nearly everything in it, you only actually load what you need. The build system can also reduce most of your dependencies to two JS files (modules + i18n bundles) with very little additional work for a well-structured application (i.e. with a main top-level module that dependencies can be easily determined from).
The documentation for Dojo and Dijit is significantly better now than years ago when it might've gotten a bad reputation for it. In addition to the reference guide, there are over 50 tutorials.
Dojo can certainly seem complex when compared with smaller or simpler libraries that don't set out to do as much, but I wouldn't bill it as any more complex than it needs to be for large single-page Web applications. In fact, I'd much sooner say that you're likely to end up with something far more complex (and less maintainable!) if you start with something that gives you far less flexibility and then find you need to cobble things together to fill the gaps.
Dojo provides a cohesive toolkit including the following out of the box:
Module dependency system (supporting AMD, the same standard that RequireJS implements)
Powerful inheritance and mixin capabilities with dojo/_base/declare
An intuitive promise-based XHR API in dojo/request, which can be enhanced/extended with dojo/request/registry
Support for localizing your application using the dojo/i18n! plugin
A full library of stylable and accessible widgets in Dijit
Cohesive data APIs in dojo/store
If you feel that you don't need all of this or are comfortable rolling your own, then that's up to you, but it's a daunting task to do all of that and keep it cohesive and maintainable, which is what Dojo gives you a head-start on.
Regarding which UI library to use, while I can't say I've used jQuery UI extensively, I would at least say that if accessibility or flexibility/extensibility are at all a concern, I would choose Dijit over it any day of the week.
To your question about using Dojo and jQuery together, Dojo generally doesn't get in the way of other libraries. Some other older libraries liked to add enumerable properties to native prototypes, which could potentially throw off unprotected for...in loops in Dojo (and anyone else's code, for that matter), but jQuery doesn't do that. Additionally, jQuery supports being loaded as an AMD module, so you can even use it with Dojo's require and define.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm the author of a fairly sized (and growing) framework. It primarily exposes JavaScript APIs, but also has public APIs in Ruby and a growing CoffeeScript segment. (CoffeeScript will eventually encompass most of the project, but there will always be a significant pure-JavaScript presence.)
Up until now, I've been documenting the JavaScript with PDoc and the Ruby with RDoc. Though I've no issues with RDoc, unfortunately PDoc is aging, high-maintenance, and requires a heck of a lot of typing that feels like superfluous clutter. Also, the transition of most of the code to CoffeeScript renders PDoc much less useful than it was.
Example of the project's current documentation
I've experimented with Rocco in a local branch and it works better than I expected. What's really nice is that it works with all my code, from Ruby to Coffee to JS. It's nice to see all the documentation in one place. It's kind of cool to see the source code next to the documentation, too, and this makes it very clear what a particular code segment is actually doing.
However, I am a bit worried about the overall structure. Docco/Rocco seems great for niche projects with very few public APIs, but its read-the-entire-project style strikes me as a double-edged sword. Though it's very informative, having to vertically scroll through the files without even a table of contents (not to mention, knowing which file to go to in the first place!) seems like it would make it difficult to actually find anything. Also, the default template required some hacking because the list of files was too long to be displayed. Not a huge deal but an annoyance, and a hint that this project may be out of Rocco's league.
I'm now considering CoffeeDoc. Judging just by the example, it seems promising, but it is of course Coffee-centric, which brings me back to running 3 separate documentation tools: RDoc, CoffeeDoc and -- what? JSDoc?
I'm not completely adverse to running separate tools for the separate sources, but it becomes hard to reconcile that into a coherent result that doesn't feel like 3 separate Web sites.
So I guess my question is: what tool do you use or suggest? What language(s) does it support? Is it easy to browse, read, and actually find a needle in the haystack that is your project? I'm even considering rolling my own tool at this point, except that I can't believe no one else has encountered a problem like this (and I don't really want to waste time if I don't have to).
Sphinx directly supports javascript. Documentation of Ruby and CoffeeScript is supported through extensions (https://bitbucket.org/birkenfeld/sphinx-contrib/).
From the website:
The following features are present, work fine and can be seen “in action” in the Python docs:
Output formats: HTML (including Windows HTML Help), LaTeX (for printable PDF versions), manual pages, plain text
Extensive cross-references: semantic markup and automatic links for functions, classes, citations, glossary terms and similar pieces of information
Hierarchical structure: easy definition of a document tree, with automatic links to siblings, parents and children
Automatic indices: general index as well as a module index
Code handling: automatic highlighting using the Pygments highlighter
Extensions: automatic testing of code snippets, inclusion of docstrings from Python modules (API docs), and more
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm investigating different documentation systems for a project keeping up. Most recently I've been using DITA and the DITA OT, but its complexity makes me want to shoot myself.
Are there any systems that provide the following functionality:
Markdown support
Reusable content (I can refer to previously defined paragraphs or terms)
Localization support
Preferably, free or open source
Preferably, allows for multiple output
I wish I could use Pandoc for this, but it doesn't appear to support reusable content.
Edit: I just ended up writing my own library for this: https://github.com/gjtorikian/markdown_conrefs
If you don't mind reStructuredText instead of markdown, Sphynx is worth a look.
You could use pandoc + pre or post processor.
That way you could easily implement snippet reuse.
This is a topic close to my heart. There's quite a lot of Markdown processor options out there, but at time of writing those are more a case of personal solutions to this persistent problem. We all tend to get frustrated, make something to help in the short term, and share it.
The challenge has been to extend this to something built for purpose and at scale. Which is where I've turned my focus to over the last few years. That includes first working on PressGang CCMS inside of a tech writing team at Red Hat, and then being inspired to spin out Corilla, a dedicated technical writing startup building the tool you require.
PressGang (the prototype)
Please refer to the PressGang CCMS project for an idea of what we did at Red Hat to build tools to solve this. The lead engineer did a run-through video that you can see on Vimeo, and I've created a public Amazon AMI if you wish to try it. It's not being maintained but it's all open source.
It's a relatively large stack written for the most part in Java, but was useful as a look into an open source project in this space. But with bias I'd suggest...
Corilla (the product)
We cofounded Corilla as an open source company to focus on bringing together the elements of content reuse and collaboration with the ease of Markdown and Asciidoc. I've spent years writing DocBook XML, and quickly built my own snippets for Sublime Text to minimise the considerable overhead of authoring in that markup. The tide is of course turning. We need easier ways to write faster, and we need them to be discoverable, reusable, and allow the entire team to generate the content in formats they require.
I'd encourage you to get involved with the beta, as the technical writing and developer community is driving the project, and as we solve our problems together. Being able to resource and drive this to market is far more rewarding than having to pick through incomplete processor chains. I've been there, it's time we did more.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I try to be very cautious with this question. There are at least three different web-development frameworks available in Smalltalk. The most prominent seems to be Seaside but there is also AIDA/Web and Iliad.
They seem to be very similiar, but this impresson may be wrong. I wonder who has tried the different tools and can share the pros/cons of the different packages.
A more concrete question would be, do yo know of let's say any software in the bookkeeing area which has choosen to use either of the three (or other) web development frameworks.
Here's one other question. What about maturity and compatiblity. Which framework can one judge as the "most" stable?
99% of my practical experience is with Iliad, so my comparison is primarily about how I got to choose Iliad instead of the others.
Seaside. Tried it first, it is the most known and the first you stumble in. I found it hard to understand (as always, no matter what you use, when it gets to real implementation you always run into issues that fit badly with the general theory), there was little documentation around and the community seemed to care little about telling n00bs how to grow up. I eventually dropped it to check Aida. You find them here: http://seaside.st/ and on IRC at #seaside
Aida. I really liked it, as Janko is extremely patient and supportive. It is large, though. I decided to use it, when I was to start implementation for our project and it was only by chance that I ran into Iliad a few days before starting. You find Aida here: http://www.aidaweb.si/ and on IRC at #Aida
Iliad. The main reason I chose it was that I had just dropped Squeak and switched to gnu-smalltalk. gst seemed to have a lot of ongoing activity on Iliad, so I reckoned I was probably going to get a better assistance with it. It is much smaller as a concept (though it does absolutely everything) and I had very little trouble in getting started and in tweaking it to what I needed for. It also proved to be well managed, as I went thru 3 releases without ever being in trouble with what I had already deployed. You get answers to questions usually in 12-24 hours max, which is fine for me. You find Iliad here: http://www.iliadproject.org/index on IRC issues are usually channeled on the #gnu-smalltalk channel
What we are doing is a GUI for a PostgreSQL database used to manage a large multimedia dictionary, that in turn produces content (among others, for KDE-edu). I have no notion of booking apps in general, so I cannot answer to your question properly.
Yet, speaking as an analyst, a booking app is mostly a DB with an online GUI, so I see no reason why you could not make it. Much will depend on how easily your db can translate into objects. You could use a RDBMS, as we did, and design tables to map objects, or use an OODBMS. Both solutions have pluses and minuses, none of them is going to have an impact on your choice of framework, I'd say.
My suggestion is that you take a month or so in making experiments and see what better fits you. I don't think there is a tool that fits everyone, we are all different and what is easy for me may be hell for someone else (and the other way round, obviously). So try your car before buying it ;)
I would not invest too much time in studying the general theory. Using a smalltalk framework is going to turn upside down the way you make a web app anyway, and your first contact is going to be full of "false friends" you inherit from previous mindsets. Your best asset is definitely going to be "how quick can I grasp what they tell me", and this is largely an individual thing, depending on you and on who you bump into. So I'd really suggest you get your hands dirty BEFORE reading too much theoretical stuff.
These frameworks are all quite different and have different goals. It would be interesting to collaboratively create some kind of comparison.
As an author of Seaside I can provide the key properties of Seaside only:
Seaside makes building web applications feel like composing traditional GUIs: components can be freely composed and reused. Sequences of components are defined using a sequence of Smalltalk statements.
Seaside has a layered architecture, providing you with high-level abstractions (components, control flow, callbacks, HTML generation, JavaScript generation, ...) over low-level concepts (HTTP, Request, Response, URLs, HTML, JavaScript). If you need to, Seaside gives you full access to low-level constructs too.
There are two Seaside books to help you get started: Dynamic Web Development with Seaside and Seaside Tutorial.
Seaside provides a tight integration into various state of the art web technologies: JavaScript (JQuery and JQueryUI), SVG, RSS, HTML5, Comet (Server-Push)
Seaside runs identically on most today's Smalltalk platforms: Pharo Smalltalk, Squeak, GNU Smalltalk, GemStone Smalltalk, VW Smalltalk, VA Smalltalk, and Dolphin Smalltalk. It is supported by all vendors of Smalltalk platforms.
Seaside provides industry proven open-source components for meta-modeling (Magritte) and content management (Pier).
Let me introduce some strengths of Aida/Web too, because as its author it would be hard to me to compare with other two frameworks. Aida strengths are:
RESTfull URLs
MVC support, every domain object can
have its own RESTfull URL, each domain class has its own web presentation class,
Integrated AJAX and Comet
support, you don't see any difference
between a traditional and Ajax
programming anymore,
Tree-like control flow for GUI-like
control flows, without need for
continuations
Building web pages programatically by
composing from components/elements
(no template based)
Scalable in complexity and performance
Integrated security with access
control and users/groups management
Ported to most Smalltalk dialects:
Squeak/Pharo, VisualWorks, Gemstone
GLASS, Dolphin, Smalltalk/X
Prime and most fresh example of Aida at work is this year Smalltalk Google Summer of
Code site.
This is the is a nice example because it was developed it in maybe a week in
total, together with a development of GSoC process in parallel and in
the same time managing that process as an admin. This site is actually
an extended Aida/Scribo CMS, with strong use of so called scriblets,
that is, dynamic web "includes" directly into the content of the site.
That way I was able to very quickly support the new ideas which come
during the evolving GSoC process.
Well, Suixo uses Seaside. Take a look at the GSoC projects we defined. Its more ERP than bookkeeping, and currently focused on healthcare.
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 5 years ago.
Improve this question
Is it my browser that doesn't work with their API online documentation?
The structure of it seems to be very bad compared to the Java API online documentation and the Yii API online documentation.
I am new to Zend Framework, so I wonder, should it be like that?
I think the API is nice, the only problem sometimes they don't give real meaning of arguments
After the API is maybe a bit behind some java examples, but I find the reference guilde quiet impressive and complete. You've got 900 pages describing every piece of the framework with short code snippet that's just wonderful.
Personally I use more often the reference guide then the API documentation.
I've been digging into Zend Framework for about a month now. I'm starting to catch on but I have to agree with the initial comment. The API documentation, at least what is available, is atrocious. What is this Dojo stuff anyway? I would expect a proper, standardized API reference for something as extensive and powerful as the Zend Framework. For an experienced software engineer the reference manual is really introductory material. Once it is digested all that is really needed is a good API reference that clearly shows properties, methods, inheritance tree, with brief descriptions where necessary. Like Java, AS3, etc. I could have saved myself about two weeks of time had I had full access to the API. I don't get it, but I intend to persevere with ZF.
For me the problem is the reference guide simply lists through all the components and has a massive page telling very long-haul uses of each component with no sort of scope of where said code should appear in your work flow.
I believe it should be re-factored to be like CakePHPs documentation, where each page is targeted at getting a specific task done, like "Saving Your Data", "Deleting Data", "Validating Data" and so on.
Real life examples with context are a lot more useful then the Zend Docs where I tend to have to guess where certain variables (commonly $db) come from - and in full MVC cases, does't even apply.