The Artima Developer Community
Sponsored Link

Weblogs Forum
How Does Language Impact Framework Design?

42 replies on 3 pages. Most recent reply: Feb 15, 2008 4:22 PM by Andy Dent

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 42 replies on 3 pages [ « | 1 2 3 ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Does Language Impact Framework Design? Posted: Jan 16, 2008 2:55 AM
Reply to this message Reply
Advertisement
You say that Wicket is an excellent web framework...why do you have to write things twice? one time in the HTML file and one in Java.

My company considered Wicket a year ago but we did not choose it because of this problem: we had to write things twice.

The only solution (that no one has done yet, I don't know why) is to completely eliminate all kinds of HTML/XML and write web applications in Java only, with a framework that mimics a GUI library (i.e. widget trees) but produces HTML/Javascript.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: How Does Language Impact Framework Design? Posted: Jan 16, 2008 4:49 AM
Reply to this message Reply
> You say that Wicket is an excellent web framework...why do
> you have to write things twice? one time in the HTML file
> and one in Java.
>
> My company considered Wicket a year ago but we did not
> choose it because of this problem: we had to write things
> twice.
>
> The only solution (that no one has done yet, I don't know
> why) is to completely eliminate all kinds of HTML/XML and
> write web applications in Java only, with a framework that
> mimics a GUI library (i.e. widget trees) but produces
> HTML/Javascript.

What, exactly, did you have to write twice? You have to write a Wicket ID twice -- once in the Java component and once as an attribute in the HTML to link the Java with the HTML, but that's about it. You do have the option sometimes of coding into the HTML sample display elements that will be replaced by the Java component, if you want to get a more realistic sense of what the page will look like once the Java component replaces the sample elements with the real once based on the model -- but you don't have to do that.

The solution you suggest (abstract the HTML away completely) has indeed been done, see Google Web Toolkit (GWT) and also in Echo and (for AJAX) Echo2. However, I suspect these have less flexibility than Wicket when it comes to customizing the look-and-feel of the pages.

Beyond that, it depends on whether you prefer using HTML to customize your look-and-feel versus doing that via API method invocations (as when building fat clients in Swing). Most people building web applications have already made a significant investment in HTML/CSS skills, and high-power tools for that are readily available -- so you're not locked into using a particular Java IDE to ease the painting of GUIs. Furthermore, you may have some pre-written HTML portions that you really want to incoroprate (e.g. standard page headers, or static pages written in HTML by others), and this is probably much easier to do in Wicket than in GWT or Echo.

HTML was _not_ designed for programmers, so I agree that any solution which requires programmers to write HTML is less than ideal. But for those who cannot or who are not willing to work in in a level that completely hides the HTML, I haven't seen anything that solves the problem as well as Wicket.

Jeff Heon

Posts: 40
Nickname: jfheon
Registered: Feb, 2005

Re: How Does Language Impact Framework Design? Posted: Jan 16, 2008 6:49 AM
Reply to this message Reply
> But now there's already one book out, and a more
> up-to-date Manning book on the way with some of the
> chapters already available online.
> (http://www.manning.com/dashorst/)
>
> Wicket can save Java on the web, and that, in turn, can
> save Java.

@Frank

Thanks for all the info.

I'm curious about something (sorry I'm being off-topic.)
My UI java experience has always been limited to web application. What would you recommend for desktop applications?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Does Language Impact Framework Design? Posted: Jan 16, 2008 8:00 AM
Reply to this message Reply
> > You say that Wicket is an excellent web framework...why
> do
> > you have to write things twice? one time in the HTML
> file
> > and one in Java.
> >
> > My company considered Wicket a year ago but we did not
> > choose it because of this problem: we had to write
> things
> > twice.
> >
> > The only solution (that no one has done yet, I don't
> know
> > why) is to completely eliminate all kinds of HTML/XML
> and
> > write web applications in Java only, with a framework
> that
> > mimics a GUI library (i.e. widget trees) but produces
> > HTML/Javascript.
>
> What, exactly, did you have to write twice? You have to
> write a Wicket ID twice -- once in the Java component and
> once as an attribute in the HTML to link the Java with the
> HTML, but that's about it. You do have the option
> sometimes of coding into the HTML sample display elements
> that will be replaced by the Java component, if you want
> to get a more realistic sense of what the page will look
> like once the Java component replaces the sample elements
> with the real once based on the model -- but you don't
> have to do that.

Ok. Let's see some examples. Let's start with the Hello World example.

You have to write the following Java code:

import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
 
public class HelloWorld extends WebPage
{
    /**
     * Constructor
     */
    public HelloWorld()
    {
        add(new Label("message", "Hello World!"));
    }
}


And this HTML:


<html>
<body>
<span wicket:id="message" id="message">Message goes here</span>
</body>
</html>


Which is pretty much the same: an HTML page declared twice, once as HTML and once as a label object inside a page object.

Ok, let's go to another example: the GuestBook. The Java code is:

public final class GuestBook extends WebPage
{
    /** Use a Vector, as it is synchronized. */
    private static final List commentList = new Vector();
    private final ListView commentListView;
 
    public GuestBook()
    {
        add(new CommentForm("commentForm"));
        add(commentListView = new ListView("comments", commentList)
        {
            public void populateItem(final ListItem listItem)
            {
                final Comment comment = (Comment)listItem.getModelObject();
                listItem.add(new Label("date", comment.date.toString()));
                listItem.add(new MultiLineLabel("text", comment.text));
            }
        });
    }
 
    public final class CommentForm extends Form
    {
        private final Comment comment = new Comment();
 
        public CommentForm(final String componentName)
        {
            super(componentName);
            add(new TextArea("text", new PropertyModel(comment, "text")));
        }
 
        public final void onSubmit()
        {
            final Comment newComment = new Comment();
            newComment.text = comment.text;
 
            commentList.add(0, newComment);
            commentListView.modelChanged();
 
            comment.text = "";
        }
    }
}


The above code builds a page with a text area, a submit button, and a list of strings.

Then we need this HTML:


<html>
<body>
<form wicket:id = "commentForm">
Add your comment here:
<p>
<textarea wicket:id = "text">This is a comment</textarea>
<p>
<input type = "submit" value = "Submit"/>
</form>
<p>
<span wicket:id = "comments">
<p>
<span wicket:id = "date">1/1/2004</span><br>
<span wicket:id = "text">Comment text goes here.</span>
</p>
</span>
<wicket:remove>
<p>
1/2/2004<br/>
More comment text here.
</p>
</wicket:remove>
</body>
</html>


Which builds again the same thing.

And I am asking you: why? the WebPage object could simply go through all of the components, produce a nice HTML object automatically.

The HTML written above is reduntant.

>
> The solution you suggest (abstract the HTML away
> completely) has indeed been done, see Google Web Toolkit
> (GWT) and also in Echo and (for AJAX) Echo2. However, I
> suspect these have less flexibility than Wicket when it
> comes to customizing the look-and-feel of the pages.

No, it has not been done.

The Google Web Toolkit translates Java code to html/javascript. It is not the Java code that produces the html/javascript.

The Echo2 toolkit (I have worked with it for a project) makes the browser a display server, ala X-Windows, using AJAX techniques. It's slow and complex.

My idea is to preserve the web page concept, complete with navigation, but not to have to write html.

>
> Beyond that, it depends on whether you prefer using HTML
> to customize your look-and-feel versus doing that via API
> method invocations (as when building fat clients in
> Swing). Most people building web applications have
> already made a significant investment in HTML/CSS skills,
> and high-power tools for that are readily available -- so
> you're not locked into using a particular Java IDE to ease
> the painting of GUIs. Furthermore, you may have some
> pre-written HTML portions that you really want to
> incoroprate (e.g. standard page headers, or static pages
> written in HTML by others), and this is probably much
> easier to do in Wicket than in GWT or Echo.

Any html coming from artists or web creators should be converted to Java code that produces the html at run-time. The workflow should be:

raw html -> java code -> compilation -> html with data.

The HTML should be treated like an Qt .ui file, i.e. as a description of the gui.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: How Does Language Impact Framework Design? Posted: Jan 16, 2008 1:16 PM
Reply to this message Reply
> > What, exactly, did you have to write twice?>
> Ok. Let's see some examples.
(etc. see above)

OK, the two versions of the page serve different purposes. The Java program lets you select pre-defined components to use, define new ones and use them, or customize/subclass old ones and use them to reflect your business logic.

The HTML page is a place to hang your .CSS decorations, which make it look pretty. Your examples use the simplest possible HTML, so you haven't taken advantage of that.

Now, let's say you have many different pages that have basically the same HTML structure, but use different Wicket components that determine the info to be displayed, and variations of the presentation that can be made via component selection or customization.

In that case, you can create a simple abstract Wicket page with matching HTML page, and then for each of the actual pages you could _subclass_ the wicket page with whatever fancy constructor variations you please -- and NOT specify the matching HTML page. In that case, the HTML page of the superclass will be used -- the HTML page will be specified but once for all of your similar pages.

That's one of the things I love about Wicket. I hate writing HTML, and I was tasked to implement an application with dozens and dozens of pages all of which had pretty much the same HTML format. I only had to write the HTML once.

Sometimes, you can do this panel by panel (a panel is an HTML fragment). I can re-use the same panel class, modifying it via inheritance or constructor parameters, to be instantiated in various ways and in various places -- never having to re-write that panel's HTML fragment more than once.

By the way, if all I want to do is change the HTML, I can trivially subclass a Wicket panel or page in a way that changes nothing, and hang a new HTML file on that subclass.

If you're comfortable with object orientation, the flexibility is amazing.

(By the way, to Jeff Heon: As for your off-topic question about learning to build Java desktop applications, you should get a book about using the GUI building toolkit you plan to use. That would be either Swing or SWT. I don't know what the best books are. Look at a variety on Amazon and look at the different reader reviews. Hint: I ignore the reviews which look too well written and heavily praise the book. I figure those were written by a professional writer whose job is to sell the book.)

Juancarlo Añez

Posts: 12
Nickname: juanco
Registered: Aug, 2003

Re: How Does Language Impact Framework Design? Posted: Jan 20, 2008 6:52 AM
Reply to this message Reply
I agree with what others have said. Java is not such a bad language, and what's annoying about it is very fixable.

The problem has been that every framework blessed by Sun has been so bureaucratic that it has been a mental challenge for programmers to use it. In aiming to cover every 0.01% case they've made the 99% cases difficult.

Take for example JSP, a flawed design that not even Struts could make bearable. Or EJB2, which had to be dropped.

In favor of Sun there is that bureaucracy and strict standardization provide a sense of assurance and safety to corporations. Against it is that the provision is often made at the expense of efficiency and "programmer happiness".

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Does Language Impact Framework Design? Posted: Jan 21, 2008 8:17 AM
Reply to this message Reply
> The HTML page is a place to hang your .CSS decorations,
> which make it look pretty. Your examples use the simplest
> possible HTML, so you haven't taken advantage of that.

Not my examples, Wicket examples.

>
> Now, let's say you have many different pages that have
> basically the same HTML structure, but use different
> Wicket components that determine the info to be displayed,
> and variations of the presentation that can be made via
> component selection or customization.
>
> In that case, you can create a simple abstract Wicket page
> with matching HTML page, and then for each of the actual
> pages you could _subclass_ the wicket page with whatever
> fancy constructor variations you please -- and NOT specify
> the matching HTML page. In that case, the HTML page of
> the superclass will be used -- the HTML page will be
> specified but once for all of your similar pages.

You can also do the same with subclassing.

>
> That's one of the things I love about Wicket. I hate
> writing HTML, and I was tasked to implement an application
> with dozens and dozens of pages all of which had pretty
> much the same HTML format. I only had to write the HTML
> once.

But if you have dozens of pages with different html format, you have a problem. And I most web apps, each page is different.

>
> Sometimes, you can do this panel by panel (a panel is an
> HTML fragment). I can re-use the same panel class,
> modifying it via inheritance or constructor parameters, to
> be instantiated in various ways and in various places --
> never having to re-write that panel's HTML fragment more
> than once.

Same thing can be done with objects.

>
> By the way, if all I want to do is change the HTML, I can
> trivially subclass a Wicket panel or page in a way that
> changes nothing, and hang a new HTML file on that
> subclass.

You can always modify a super class.

>
> If you're comfortable with object orientation, the
> flexibility is amazing.

HTML is anything but object-oriented.

You could achieve the same flexibility using code only, without any HTML.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: How Does Language Impact Framework Design? Posted: Jan 22, 2008 7:10 AM
Reply to this message Reply
> > The HTML page is a place to hang your .CSS decorations,
> > which make it look pretty. Your examples use the simplest
> > possible HTML, so you haven't taken advantage of that.
>
> Not my examples, Wicket examples.

Well, yes. Those are examples used for teaching Wicket, not for motivating the use of Wicket. Indeed, that's a complaint I have about quite a lot of documentation -- lots of material on how to do this or that, but relatively little on _why_ things are done that way. (I find that's especially true with books on Windows technology BTW, though Petzold is a rare exception.)

> > Now, let's say you have many different pages that have
> > basically the same HTML structure, but use different
> > Wicket components that determine the info to be displayed,
> > and variations of the presentation that can be made via
> > component selection or customization.
> >
> > In that case, you can create a simple abstract Wicket page
> > with matching HTML page, and then for each of the actual
> > pages you could _subclass_ the wicket page with whatever
> > fancy constructor variations you please -- and NOT specify
> > the matching HTML page. In that case, the HTML page of
> > the superclass will be used -- the HTML page will be
> > specified but once for all of your similar pages.
>
> But if you have dozens of pages with different html
> format, you have a problem. And in most web apps,
> each page is different.

I guess I've been working on different kinds of applications than most people, then. If what you say is true -- that combinations of GUI elements rarely repeat themselves in the typical web application, that would explain Microsoft's emphasis on making it easy to paint individual screens for one-time use at the expense of refactoring ease.


> > If you're comfortable with object orientation, the
> > flexibility is amazing.
>
> HTML is anything but object-oriented.
> You could achieve the same flexibility using code only,
> without any HTML.

Well, yes that's true if you have a satisfactory web framework that eliminates the developers' need to work with HTML pages or strings containing HTML snippets (the need for escape characters makes the latter especially ugly in Java).

Do you know of a framework to recommend? I had long hoped that Java Webstart would solve this problem, but there always seems to be unresolved obstacles precluding its widespread use.

Leon Liu

Posts: 1
Nickname: beyondliu
Registered: Jan, 2008

Re: How Does Language Impact Framework Design? Posted: Jan 25, 2008 8:03 AM
Reply to this message Reply
Java is just not fun to play with. Python is a language that you can play with. This is a very brief sentence. But it definitely has a lot of specific meanings.

Also I don't know if the assumption that Java is better suited for large scale enterprise projects is a right one.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Does Language Impact Framework Design? Posted: Jan 25, 2008 8:22 AM
Reply to this message Reply
> Do you know of a framework to recommend? I had long hoped
> that Java Webstart would solve this problem, but there
> always seems to be unresolved obstacles precluding its
> widespread use.

I haven't found one such as I described earlier.

Gregg Irwin

Posts: 16
Nickname: greggirwin
Registered: Jan, 2004

Re: How Does Language Impact Framework Design? Posted: Jan 25, 2008 1:46 PM
Reply to this message Reply
Can you build a framework that is more flexible than the language it is built upon? Higher level, yes. More abstract, yes. More flexible...I don't think so.

More importantly, it's likely that you're writing a framework because you work in the language you're writing it for, so the design of the language itself may heavily influence your framework design, intentionally or otherwise.

If we liken Frameworks to visual filters, it may be that they blur and smooth, making them look less like the language, or they may sharpen and clarify, emphasizing the base language deisgn, for better or for worse.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: How Does Language Impact Framework Design? Posted: Jan 28, 2008 7:13 AM
Reply to this message Reply
> Can you build a framework that is more flexible than the
> language it is built upon? Higher level, yes. More
> abstract, yes. More flexible...I don't think so.

Surprisingly, I found Wicket to be more flexible than Java. When attaching a web component to an element of a POJO as its model object, Wicket provides an expression language that is a very useful subset of OGNL (Object-Graph Navigation Language). In many places the user can enter a string that is interpreted as a series of method calls. I think this provides much of the power and convenience of scripting languages.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: How Does Language Impact Framework Design? Posted: Feb 15, 2008 4:22 PM
Reply to this message Reply
Elizabeth Wiethoff wrote
> At least C (well, C++, 'cause I'm not up on C) doesn't let
> a function be defined more than once. Attempts to do so
> are caught by the compiler or linker.
True. Most build systems will at least warn of duplicates.

> Therefore, ...you know that
> the function your tests exercise is the same function that
> gets invoked when the full app runs in the real world.
False assumption and I've seen it catch a few people over the 15 years or so I've been working in C++. I'm sure I'm one of the victims.

If you are linking statically, then the library that is linked will be the one found by the linker at the time of linking based on the build instructions, including the paths configured in your IDE. Because of the separate compilation, that library only needs to match the signatures of the header files with which you compiled. It is therefore possible to have a build error where your unit tests point to one set of libraries or even recompile a set of source that your main program doesn't see.

Similarly, with dynamic libraries, it is possible to encounter a different library at runtime. For example, under Windows, you might have a local DLL sitting there next to your unit tests and therefore overriding the installed version for the system. A particularly subtle, nasty form of this bug is when a build instruction copies in the DLL from a known area, so it only exists at the time of running or building but may not be there for you in the build area if you inspect before the build.

These problems are exacerbated by the poor visibility of settings in common IDEs such as Visual Studio (up to 2005 at least). It is often hard to compare paths in different build targets and to propagate corrections.

Flat View: This topic has 42 replies on 3 pages [ « | 1  2  3 ]
Topic: How Does Language Impact Framework Design? Previous Topic   Next Topic Topic: Optional Static Typing -- Stop the Flames!

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use