Discussions

News: Taconite 1.0 Released

  1. Taconite 1.0 Released (26 messages)

    Taconite 1.0, an Apache-licensed open source framework that simplifies Ajax development, has been released. Taconite consists of a client-side javascript library that reads an XML document via AJAX, which tells the client side how to render a specific operation. It also has a set of JSP tags to easily construct the clientside operations, although the XML can be constructed without JSP as well.

    Taconite is based on concepts from the W3C DOM Level 3 Load and Save specification. Taconite aids in the development of Ajax-enabled applications by allowing the developer to specify new or updated content as XHTML, and automatically updates the current Web page's DOM based the XHTML content As such, Taconite eliminates the need to write document.createElement and document.appendChild statements to update the DOM, common in many AJAX libraries, thus avoiding the occasionally problematic innerHTML property and specific browser quirks.

    The Taconite client-side library encapsulates the details of creating the XMLHttpRequest object, building the query string that is sent to the server as part of the request, and the handling of the server response. Using Taconite, an Ajax request can be created and sent with four lines of JavaScript code.

    Unlike some other frameworks, Taconite can be used with any server side technology, be it Java EE, .Net, PHP, and others. As long as the server can generate some XML, it can be used with Taconite, although a JSP tag library is supplied.

    Threaded Messages (26)

  2. is your java code compiled with java 1.5? could it be compiled with 1.4.2?
  3. is your java code compiled with java 1.5? could it be compiled with 1.4.2?

    I think it's compiled with 1.4 but I can check if you're having trouble.

    Ryan Asleson
    Taconite
  4. the error msg i get...[ Go to top ]

    i get this error when i explode your .war into my tomcat (hehe) and start it up...

    java.lang.UnsupportedClassVersionError: net/sf/taconite/compression/CompressionFilter (Unsupported major.minor version 49.0)

    i have tomcat 5.0.28, java 1.4.2_08-b03.
  5. the error msg i get...[ Go to top ]

    OK, it looks like it's compiled as 1.5, not 1.4 as it should be. I'll change it and post it later today.
  6. Thanks![ Go to top ]

    OK, it looks like it's compiled as 1.5, not 1.4 as it should be. I'll change it and post it later today.
    Thanks! i really want to take a look at your library.
  7. Thanks![ Go to top ]

    OK, it looks like it's compiled as 1.5, not 1.4 as it should be. I'll change it and post it later today.
    Thanks! i really want to take a look at your library.

    I just uploaded a new version (1.0.1) to the sf.net download page, this time compiled using JDK 1.4.

    Ryan Asleson
    Taconite
  8. Thanks![ Go to top ]

    FYI, the taconite.jar in the .war file did not get updated with the new build.
  9. Thanks![ Go to top ]

    oops. spoke too soon. the .jar file in the build directory has today's date on it. but the .class files in it were built a month or so ago (with the java 1.5 version evidently).
  10. Thanks![ Go to top ]

    oops. spoke too soon. the .jar file in the build directory has today's date on it. but the .class files in it were built a month or so ago (with the java 1.5 version evidently).

    Oops... Must have forgotten to do a clean before the build. A new release (1.0.2) is on the sf.net download page.

    Sorry and thank you for the heads up!!
  11. Taconite 1.0 Released[ Go to top ]

    Does anyone have a comparison of all these AJAX libraries out now?

    Seeing as how AJAX is the new buzzword and everyone is scrambling to build the killer-lib for it, a comprehensive comparison would be advantageous to all of us.

    STAY METAL!
    Roy Russo
  12. Taconite 1.0 Released[ Go to top ]

    Does anyone have a comparison of all these AJAX libraries out now?

    U may want to go through the extensive documentation posted at
    http://ajaxpatterns.org/Ajax_Frameworks

    Claude Hussenet
    http://claudehussenet.com
  13. didn't see it in an example, but how does your javascript functions that retreive values for named objects handle multiple forms on a page that could possibly contain form elements with the same name? (as i understand it, id's should be unique on a page, but name's don't have to be).
  14. didn't see it in an example, but how does your javascript functions that retreive values for named objects handle multiple forms on a page that could possibly contain form elements with the same name? (as i understand it, id's should be unique on a page, but name's don't have to be).

    Right now it won't differentiate between elements with the same name but on different forms. For those situations I recommend using the id attribute instead of the name attribute. For the most part, using the name attribute is best used for separate elements that have the same value, for example, radio buttons.

    Ryan Asleson
    Taconite
  15. Taconite 1.0 Released[ Go to top ]

    I read through the gettting started guide:

    http://taconite.sourceforge.net/getting-started.html

    And I read some of the examples:

    http://taconite.sourceforge.net/examples.html

    I like what I see. I like the fact that I can do a lot of AJAX type stuff (yes that is a very technical description) without writing a ton of JavaScript.

    I like the declaritive style of the XML actions:

    http://taconite.sourceforge.net/actions.html

    It would be good if you take some of the examples (or similar examples) that are in Ajax In Action and implement as Taconite examples.

    I guess I'd really like to see more examples.

    I'd like to use it in anger before I gave an endorsement, but I really like what I see.

    Thanks.
  16. taconite[ Go to top ]

    "Taconite" -- that's thursdays at my house.

    Oh, was it named after the mineral? my mistake, sorry.
  17. taconite[ Go to top ]

    "Taconite" -- that's thursdays at my house. Oh, was it named after the mineral? my mistake, sorry.

    Great minds think alike:

    Taco-nite: Have you heard of the Taco framework?

    Either that or we both have the same stunted sense of humor.
  18. Taconite 1.0 Released[ Go to top ]

    it took 3 minutes to write my first AJAX "hello world" app. nice.

    pascal
  19. Taconite 1.0 Released[ Go to top ]

    Not sure that I like the idea of creating a div in one page and referencing it in another. I found the rails approach quite nice where you like to a method (not too different to linking to a jsp here) and then specify the div you want to put the data into and also whether you want to replace the existing text in the div or append the response to the existing text.

    a link would be something like...

    var ajaxRequest = new AjaxRequest(url,"myDiv","after");


    ...which would make the request and put the response into the div named "myDiv" after the existing content. That way, everything is kept on a single page and (IMO) it makes it a little easier to read for the poor developer that has to support it later :P
  20. Taconite 1.0 Released[ Go to top ]

    Have you seen this component from Coldtags suite: http://www.servletsuite.com/servlets/ajaxdivtag.htm ?
  21. take a look at easyajax[ Go to top ]

    I have opened easyajax.sourceforge.net project, now, it is still in its initial stage. but provide some interesting features.

    easyajax based on prototype, it provide:
    1. a lightweight component model which bind with the DOM. each DOM element can have a related javascipt component, process dynamic behavior.
    2. Data Binding. very magic, now, we can using #{expr} to dynamic updating the content, the behavior and more. Data Binding also makes HTML template more visible. We can using common visiual HTML editor to design/edit the page, without asp/jsp tags.

    3. XML to Javascript mapping, something like JAXB in java, but take advantage of javscript. now, we can access XML without DOM.
    4. RPC. easyajax aims to call webservice in javascript directly. but now, it implements a lightweight rpc stack. easyajax support pass and return complex data structure which can be presented using XML.

    Hopes your comments.
  22. Taconite 1.0 Released[ Go to top ]

    Can not suff Taconite's site. It ask me password!?!
  23. Taconite 1.0 Released[ Go to top ]

    Can not suff Taconite's site. It ask me password!?!

    Use the Taconite home page at taconite.sf.net. This page has links to examples and the sf.net download page.

    Ryan
    Taconite Lead Developer
  24. AJAX philosophies[ Go to top ]

    I've seen several philosphies on how AJAX should be used. Some look at it as a way to do RPC to return data ot the client for it to act upon. Part of this philosophy is to be able to call any old web service and consume the returned data.

    Another philosophy is to return information that acts directly upon a page. This requires that the se rver-side functionality be purpose-built to serve the page in question. Alternatively, one could build a generic framework that allows the client to parse client-side UI commands generated by the server.

    In my opnion, Taconite falls into the latter case. I've personally tried both extremes, but I don't yet favor one or the other.

    What do others think? Should server-side AJAX functionality be returning UI information for a dumb client or data for a smarter client?
  25. AJAX philosophies[ Go to top ]

    I'd prefer the RPC approach since the second one tend to mix concerns.
  26. It's like asking java or javascript[ Go to top ]

    I've seen several philosphies on how AJAX should be used. Some look at it as a way to do RPC to return data ot the client for it to act upon. Part of this philosophy is to be able to call any old web service and consume the returned data.Another philosophy is to return information that acts directly upon a page. This requires that the se rver-side functionality be purpose-built to serve the page in question. Alternatively, one could build a generic framework that allows the client to parse client-side UI commands generated by the server.In my opnion, Taconite falls into the latter case. I've personally tried both extremes, but I don't yet favor one or the other.What do others think? Should server-side AJAX functionality be returning UI information for a dumb client or data for a smarter client?

    I think there is no single yes/no answer to this. But let's ponder upon it a bit:

    If your server side app is targeted to a specific group (say, veterinarians in rural areas, or some such), then possibly the combined computer power on the client side is less than what you have on the server.

    OTOH, if the app is targeted to "everybody" (like google), then the combined client side power is orders of magnitude bigger than yours.

    Another way of looking at this is, for what do you need computing power? Is it for the processing, for the UI, or for "appearance of quickness"?

    Then again, your particular product (or "solution") might inherently dictate that processing should mainly be done in one end.

    Examples of inherently client-heavy apps would be any real-time display of things (like stock graphs accrate to the minute, vehicles or customers passing a point, or any industry process remote monitoring), on line games (multi-player, or just many clients), special browsers (like having your family pictures on the server, while the browser smartly preloads, caches, initially loads thumbnails, etc. to give an "instantaneous" response).

    Examples of inherently server-heavy apps would be on-line telephone directories, google, or any app where the displayed data must be combined or mangled or selected from vast amounts of raw data.

    To recap, there is no a priori answer to this. You simply have to consider the hard facts, the needs of the participants, the size and capacity of both the customers, their machines, and the server hardware.
  27. AJAX Philosophies - redeced[ Go to top ]

    Ajax Framework requirements:

    Problem space:

    There are many ways the AJax frameworks have attempted to solve the server client (browser) interaction domain.
    Each solves smaller problems that tends to create other problems or narrows the patterns of interation that can easily be used as a result.
    Many programmers start with a framework and then realise they are trapped into an interaction patterns that is not suitable for what they need to do a month later.
    This is not optimal and leads to headaches.

    Reference for a good description of the problem space and the pattenrs of interaction used.
    http://java.sun.com/developer/technicalArticles/J2EE/AJAX/



    Learning from this the following is required of a library:
    1. STATE is ONLY handled on the client. This is the golden rule. We dont want our server be to stateful, as the client can change state without the server knowing.
    As a consequence the server is a web service.
    The page just does the initial layout and loading of the javaScript modules and nothing else. Similar to a manifest.
    The body OnLoad can be used to interact with the server to load data, and hence render the page. Hence very chatty.

    2. Client can hold state in either JavaScript Or DOM. This is useful to give versatility as to how the programmer wishes to work with state.
    Simple clients (e.g. Forms) can just use the DOM as state, because thet are not going to be messing with the DOm too much.
    Complex clients (e.g google maps etc) can use javaScript as required.
    3. Encapsulation is vital. Hence MVC.
    Just as we are encapsulating State onto the client, we need to control the interacts.
    FOr example, a request could return data, which is then rendered to the page. Even Javascript could be rendered to the page dynamcially.
    THis javascript may have a dependency on some other javascript libary. How does it know if its there?
    Hence, use delegate and events in an MVC way.
    Model - this is essentialyl the state. This is the javascript (or the DOM), depending on where you want your state contained.
    I prefer javaScript from the outset, but it relies on a client side state container, as using globals in javaScript is evil and creates hug bugs.
    View - the DOM is the view
    Controller - the javaScript.
    * Each MVC can be encapsulted with another of course. You coudl even load up a complete component with all the MVC code in it dynamcially as a result of a call to the server.

    Consequences (advanatges and then some):
    On the Server:
    This has many advantages in temrs of scalability and redundancy as the server is stateless, which removes scaling out problems.
    It also means reuse the of web service for different clients.
    You can use interfaces or inheritance to help layer what services are availble to what clients too.
    From an Authourisation point of view it also makes it easy as you are are not mixing between the client and the server.
    The initial page needs to only server up functionality that the client is authoursied to call. Thsi shoudl be relatively easy to do dynamically using a Demand pattern when rendering your page
    to ensure only certain page parts are rendered.
    On the Client:
    You have seperated out your concerns into a pattern that you know will not lead to a dead end technically and get you into trouble later.
    You have a less buggy environment because the JSON objects can by generated at runtiem or design time. Hence you can use static JSON objects and XML whislt you are
    working in the Ui realm, and then start talking to the server for real as you iterate over development phases. Nice!!!

    The down side is that the Page and the Web service are NO longer linked on the server. You may want to server a page froma web server, and dump it out on the client.
    ANyway the poihnt is that all those Asp.NET controls, etc are useless.
    All the client side javascript widgets however are vital.
    I personally feel this is worth it. The ASP.NET controls and databinding model is pretty terible anyway, so i would rather move this to the client anyway.



    The taconite lib fails in a couple of these respects.
    1. The state is assumed to be on the server. It also assumes that the DOM has not changed between request / response calls.
    If the client javascript has changed the topology of the DOM, the Taconite response will fail !
    This will trap the developer into simple forms based ajax web sites that do not transform the DOM using javascript.

    But all is not lost:
    The ability to navigate the DOM varies vastly between clients, so a standard way of interacting with the DOM is useful. This si where the Taconite libary is worthwhile,
    but i wan it on the client. You could take the XML from the web service to create the Taconite XML, and then execute that to update the DOM. I REALLY like this model for interacting with the the DOM. The client stays the controller (in MVC speak) rather than the server, yet i get the browser independence by using the Taconite library client side.

    You could easily create a library to create the Taconite XML on the client using string manipulation, rather than XSLT which tends to be buggy (and time consuming) on a client. Or the Taconite developers could provide a nice client side wrapper for creating Taconite XML on the client !!