I came across this phrase "implementing a DOM" and want to ask what does that mean exactly?
I think DOM is implemented by C++ in most browser. and DOM API is exposed to users through Javascript? So what does it mean to implement the DOM using PHP/Java or even Javascript such as jsdom did.
A more specific question is why would people want to re-implement DOM using other languages?
Thanks
I think DOM is implemented by C++ in most browser. and DOM API is exposed to users through Javascript?
Maybe. I'm sure that Internet Explorer uses MSXML for manipulating the DOM. As it's a set of COM components, it is available for use in many different languages. It's likely that this implementation is written in C++, but it doesn't really matter from the application's point of view.
So what does it mean to implement the DOM using PHP/Java or even Javascript such as jsdom did.
DOM is the recommended application programming interface for working with XML documents. Implementing a DOM basically means implementing an XML parser and tree structure library that complies to this interface.
This is API is a convention. It allows people familiar with DOM manipulation to "feel at home" when they use a new library. This usually happens when you use another language (e.g. server-side Java, Python, Ruby and client-side JavaScript), but may happen if you start using another project in the same language, but that project uses a different library.
A more specific question is why would people want to re-implement DOM using other languages?
Because not everyone agrees on which programming language to use. If you really like Haskell and you choose to manipulate documents in XML format (i.e. persisting data, or for communication with other software that understands XML -- web scaping, for instance), then you'll need to manipulate XML documents in Haskell. Then, you'll need a library for XML in Haskell.
Note that, even if people agreed on a single programming language, there would probably still be many different libraries as people disagree on political grounds, such as software licensing issues and programming style, desired features, etc.
Related
Which Markup Language do you use for user comments and other user generated content when building web applications for Java EE? I.e. if you were to code SO in Java, what would you use to parse the questions.
I have already found some markup languages (Markdown, Textile, BBCode, Creole...) and some of them seem to have a Java implementation, but I have not found a well-established mainstream one (for Java). Most of the related projects don't seem to be very active. For example in the MarkdownJ forums I read "I agree with you about creating anew implementation not based on regular expressions, and as such, there's a new ticket [...]" and users are reporting strange Exceptions.
I can't believe there's no standard solution. Is there any markup language you would usually use for Java projects? Can someone name a large web site using Java and (preferably an open source) compiler for a markup language like Markdown? Is using plain old HTML with some validation the default way to go?
I played with Mylyn WikiText as have others, but it's a specific format. IMO it doesn't matter a huge amount, particularly since a converter for essentially every syntax is available for the JVM, even if you end up switching languages.
Filtered HTML is fine, but it's a PITA to write in.
Honestly, I'd just pick one, or tweak one--I ended up using a combination of mostly-markdown, but with embeddable macros like XWiki/Confluence etc. originally pulled from the XWiki syntax parsing but modified. In my head I'm still working on it; in reality... not so much.
I have a simple web application testing desktop application. I am wondering how I can create my own scripting language for it (Domain Specific Language).
The purpose of this is to offer a very intuitive scripting even for non programmers, and able to define user scenario specific details.
I hope this is clear, basically the question is, how do I create a simple-to-use scripting language that can be translated into Java code.
Perhaps, they can use netbean's IDE to write the scripts.
For ex)
my script:
load "http://www.google.com";
click "Search" button;
java code:
browser.navigate("http://www.google.com";
browser.wait
browser.element("Search").click();
The best tool/framework for languages which extend beyond very simple grammars is to use ANTLR. Its a full featured lexer+parser combination, great Java integration, and tons of examples with good documentation.
Do realize that this isn't a trivial project to get right. You should use an existing language if your time is limited
The best solution would be to reuse one the existing scripting languages for Java; for example BeanShell. Implementing your own scripting language would be whole a lot of work. And if you've never done any language design and implementation work before the results are likely to be "less than stellar".
Perhaps, they can use netbean's IDE to write the scripts.
Expecting users of your application (especially non-programmers) to install and use a particular IDE sounds like a really bad idea.
... that can be translated into Java code.
Translating to Java code complicates things as well. It is probably better to interpret a scripting language and access Java APIs using a combination of staticly typed method calls and (only where necessary) the Java reflection APIs.
I am not sure exactly what I am asking....The guys that do the software development for the company I work for write everything in VB. I am currently the Web developer for this company and I specialize in Flex apps. I am thinking about expanding into their area. But I do not want to do VB, I don't mean to bash on VB but the coding syntax is not for me. So I am wondering if Java can integrate with VB? Also not sure if it matters but I think everything they do is procedural, and I will be doing OOP.
Thanks.
There are lots of integration opportunities, but before examining them, if I were you I would re-examine the question itself.
It should be exceptional to introduce a new language into an established project. The desires or aesthetic preference or skillset of a single developer is not a good enough justification to do so. Introducing a new language into a project should be a strategic decision for the project, not a backhanded one.
If you do choose to expand the core languages used to develop the system,
COM interop
is possible with JACOB. I believe IBM has a bridge as well.(Check alphaworks)
Java-.NET bridging
is possible via JNBridge and other bridges. This makes sense only if VB.NET is in use.
SOAP, XML document exchange, REST
suitable over a services boundary. It requires TCP or HTTP or some network protocol.
common data stores
can serve as a rendezvous point. Both Java and VB can read and update data in SQL Server, Oracle, MSMQ, MQSeries, and so on. Even a filesystem can be an integration point.
Think of data format as related to, but ideally independent of, the integration mechanism. What I mean is: You can use an XML document for integration, whether it is stored in a database, or sent over a REST interface, or stored in a filesystem, or put/get on a queue. You can use a comma-separated file over any of those mechanisms as well.
Potentially they could expose a service layer via soap or something simpler? Also you could always work against the same database with different languages however unless most of the logic is in stored procedures (not necessarily recommending this approach) then you end up with repeated code.
Not really. Java uses CORBA for interop, and VB uses COM for interop. You may be able to make a bridge using JNI, but I understand that can be quite the pain.
I haven't done this by I believe you have the following options:
Use the Java-COM bridge, as VB uses COM. This library was already mentioned here several times
If you are using VB.net, you probably use hessian, As it has both Java and C# implementations.
You could bridge the two using a C/C++ adapter to map JNI calls with COM. But that would be horrible. I hope there is a better solution, but my understanding is that it is pretty hard to integrate .NET code and Java as both vendors (Sun and Microsoft) don't have any incentive to streamline that kind of development.
Iam a great fan of javascript frameworks especially jQuery .I have always wanted to design sites like "plurk.com" but i know that it needs very huge lines of javascript.so that shut me off.But since i came to know GWT , i really want to test it out and want to ask you if it makes our job easier to develop complex things than with the javascript or its frameworks .Which one would you prefer ?
I think a few of the answers on this question are quite un-informed, and I suspect that the people answering them have never used GWT on large scale projects. Yes GWT is a great way to do large AJAX websites, and for large complex sites, involving a back end as well, it kicks things like JQuery up and down the park. The way I always look at it is that javascript on it's own is great for doing small client side things. When you need to do something more complex (like dynamic fields, popups, animations) you bring in something like JQuery or Prototype. When you want to take it one step further you go with GWT.
People assume that because you write it in Java, it's designed for back end developers to do front end development. It's not. Java is simply the language that they chose, mainly because it's widely used, statically typed and there are lots of good editors out there for it.
I don't buy the leaky abstraction theory either, it doesn't try to fully abstract out the HTML elements, as it gives you direct access to both native javascript and the DOM if you choose to use those.
In short we've built very complex sites (one of which was featured on the GWT blog) in GWT, and also using other libraries like JQuery. I can tell you with 100% confidence that once you get your head around GWT it kills those other frameworks dead for complex tasks. It also has some great built in things that help make things better, and even does some things that no other framework supports (like the magic it can do with images). See this blog post for more details:
http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html
Few things scare me like "generated Javascript". The Law of Leaky Abstractions has got to be doubly true in these cases.
Writing effective cross-browser javascript is a tricky process of continuous refinement. Trying to decipher where some generated, obscured Javascript is going wrong is a major headache. It's bad enough fixing bugs in the pure JS libraries.
To me, GWT is a trick aimed at allowing backend developers to write front-end, in-browser code. Unfortunately, the realities of modern web apps mean you just have to know Javascript and the DOM. Something's going to break, and you're going to need to know why.
I think you're better off picking a good javascript library like jquery or prototype, and learning that well. Those libraries abstract away the sort of stuff that SHOULD be abstracted away and is unlikely to break in edge cases, like array operations and AJAX requests.
Yes, it does, since you'll be using Java and not Javascript.
Superb IDEs, static code analysis, searching and refactoring - all this will make your life much easier on large projects.
No. It doesn't.
It doesn't remove the complexity, it just makes it possible for you to deal with it from a Java Perspective. Since that gives you all the Tooling available from Java... that alone might make it worthwhile.
JavaScript IDEs are getting better and better though, and typically if you're using a Framework like jQuery or Prototype, then you're probably going to find it easier than dealing with a heavy weight abstraction layer like GWT.
My personal preference is to take the pure JavaScript approach, but that's because I like being able to work more closely to metal, and I'm disciplined enough to tame my JavaScript cats.
With GWT, you're not actually writing JavaScript; it's entire value proposition is that you can write Java that it will compile down to JavaScript for you.
I'm working on a project that has used GWT to pretty good effect. It's a good choice for us since we're all primarily Java developers working on internal tools. I can't speak to how useful it is for large end-user sites.
One advantage I particularly appreciate is the seamless object serialization and deserialization. Not only are the details of XML-RPC abstracted away, but since the same Java code is compiled to byte code for the server and javascript for the browser, you can code almost as if the server and client were running in separate class loaders in the same JVM. For instance, you can construct a Java object on the server, send it to the browser as the return value from an RPC service call and the browser code can then use the identical Java class to manipulate the object you just returned. Likewise, parameters to RPC calls can be constructed as Java objects, with the server receiving an identical Java object on the other end. All this without mucking about in the details of (de)serialization.
On my current project, we've been using Struts 1 for the last few years, and ... ahem ... Struts is showing its age. We're slowly migrating our front-end code to an Ajax client that consumes XML from the servers. I'm wondering if any of you have migrated a legacy Struts application to a different framework, and what challenges you faced in doing so.
Sure. Moving from Struts to an AJAX framework is a very liberating experience. (Though we used JSON rather than XML. Much easier to parse.) However, you need to be aware that it's effectively a full rewrite of your application.
Instead of the classic Database/JSP/Actions scheme for MVC, you'll find yourself moving to a Servlet/Javascript scheme whereby the model is represented by HTTP GET requests, actions are represented by POST/PUT/DELETE requests, and the view is rendered on the fly by the web browser. This leads to interesting challenges in each area:
Server Side - On the server side you will need to develop a standard for exposing data to the client. The simplest and easiest method is to adopt a REST methodology that best matches your data's hierarchy. This is fairly simple to implement with servlets, but Sun also has developed a Java 1.6 scheme using attributes that looks pretty cool.
Another aspect of the server side is to choose a transmission protocol. I know you mentioned XML already, but you might want to reconsider. XML parsers vary greatly between browsers. One browser might make the document root the first child, another one might add a special content object, and they all parse whitespace differently. Even worse, the normalize() function doesn't seem to be correctly implemented by the major browsers. Which means that XML parsing is liable to be full of hacks.
JSON is much easier to parse and more consistent in its results. Javascript and Actionscript (Flash) can both translate JSON directly to objects. This makes accessing the data a simple matter of x.y or x[y]. There are also plenty of APIs to handle JSON in every language imaginable. Because it's so easy to parse, it's almost supported BETTER than XML!
Client Side - The first issue you're going to run into is the fact that no one understands how to write Javascript. ESPECIALLY those who think they do. If you have any books on Javascript, throw them out the window NOW. There are practically no good books on the language as they all follow the same "hacking" pattern without really diving into what they are doing.
From the lowest level, your team is going to need remedial training on Javascript development. Start with the Javascript Client Guide. It's the de facto source of information on the language. The next stop is Douglas Crockford's videos on Javascript. I don't agree with everything he has to say, but he's one of the few experts on the language.
Once you've got that down, consider what frameworks, if any, you want to use. Generally speaking, I dislike stuff like Prototype and Mootools. They tend to take a simple problem and make it worse. None the less, you can feel free to evaluate these tools and decide if they'll work for you.
If you absolutely feel that you cannot live without a framework because your team is too inexperienced, then GWT might fit the bill. GWT allows you to quickly write DHTML web apps in Java code, then compile them to Javascript. The PROBLEM is that you're giving up massive amounts of flexibility by doing this. The Javascript language is far more powerful than GWT exposes. However, GWT does let Java developers get up to speed faster. So pick your battles.
Those are the key areas I can think of. I can say that you'll heave a sigh of relief once you get struts out of your application. It can be a bit of a beast. Especially if you've had inexperienced developers working on your Struts model. :-)
Any questions?
Edit 1: I forgot to add that your team should study the W3C specs religiously. These are the APIs available to you in modern browsers. If you catch anyone using the DOM 0 APIs (e.g. document.forms['myform'].blah.value instead of document.getElementById("blah").value) force them to transcribe the entire DOM 1 specification until they understand it top to bottom.
Edit 2: Another key issue to consider is how to document your fancy new AJAX application. REST style interfaces lend themselves well to being documented in a Wiki. What I did was a had a top level page that listed each of the services and a description. By clicking on the service path, you would be taken to a document with detailed information on each of the sub-paths. In theory, this scheme can document as deep as you need the tree to go.
If you go with JSON, you will need to develop a scheme to document the objects. I just listed out the possible properties in the Wiki as documentation. That works well for simple object trees, but can get complex with larger, more sophisticated objects. You can consider supplementing with something like IDL or WebIDL in that case. (Can't be much worse than XML DTDs and Schemas. ;-))
The DHTML code is a bit more classical in its documentation. You can use a tool like JSDoc to create JavaDoc-style documentation. There's just one caveat. Javascript code does not lend itself well to being documented in-code. If for no other reason that the fact that it bloats the download. However, you may find yourself regularly writing code that operates as a cohesive object, but is not coded behind the scenes as such an object. Thus the best solution is to create JSDoc skeleton files that represent and document the Javascript objects.
If you're using GWT, documentation should be a no-brainer.
Check out the Stripes Framework. If you are familiar with struts then stripes will make sense to you, but it's so much better. They have a Stripes vs Struts section on their website. You could check that out and see if it interests you. It allows you to work with any ajax framework you want, and I don't think it would take long to migrate from struts to stripes.