I want to use a tree in my Scala swing application, but the component isn't available in the API.
Does a wrapper of JTree exists ?
If not, do you have any advice for making it ?
Thanks
Even though you can use directly the Java JTree in your scala program, as illustrated by this thread, there is a debate about including a Scala wrapper of a JTree.
The following common usages are tedious, verbose, non-type safe, and/or require unsafe null usage:
Creating a custom tree model, backed by your own user objects -- the Scala
Swing way would be to have a standard typesafe Map behind it
Events - there are heaps of events created by trees -- TreeWillExpandListeners, TreeSelection, etc -- Using the Reactor/Publisher PartialFunction model would make this code far more readable and concise.
Editable components -- This is done with implicit values elsewhere in scala.swing, and should be here too.
Custom renderers -- Can't remember how Scala deals with these, but this is always fiddly in Java Swing too.
Bottom line is, JTrees are a massive pain to use in Java, for no particularly good reason. A Scala wrapper would be a massive boon for Scala Swing users.
A design is in progress, and a JTree wrapper proposal is available in this GitHub repo, made by kenbot (Ken Scambler).
Related
If I wanted to create a "good old" desktop GUI program with some basic selectable vector graphics (arrows, colored boxes, text) to show mostly text and some diagrams (no need for 3D or particles, etc.) that then can be edited by the user, which Scala library would I use, and why? I'd want to build a tool for something similar to drawing diagrams.
Mostly I don't want to use things like D3.js or other web SVG stuff because it is painfully slow and can't show the amounts of content I want it to. But if there are exceptional advantages by using, say, Scala.js, for this purpose, it could be still of interest if there are no better means.
Alternatively, someone can point me to where this had been discussed? Did not find anything on Google or here.
Scala-Swing is a wrapper for Java Swing which is quite nice. As you may know, below Swing lies Java2D, so you will most likely want to look for Java2D based libraries. There aren't that many for Scala that I'm aware of, but more for Java (which you can easily use).
JFreeChart and scala-chart - more for charting
JGraph
JUNG
Processing might have some libraries for your use case
JHotDraw - not sure it's still maintained
NetBeans - not sure it's still maintained
Prefuse
And of course, if it's simple enough, there is nothing wrong with using Java2D directly.
I want a simple timeline component (like in video editing software) for a clojure/seesaw app and I am wondering if it is a good approach to implement this directly with clojure and seesaw or if I should write it in java and make my clojure wrapper around it.
Or more generally: is a functional programming language optimal for writing UI widgets? I cannot imagine doing that without a lot of state involved. And wasn't OO invented for UI-development in the first place?
You could go either way. On Overtone, we've built a number of custom graphical components directly in Clojure with Seesaw. Many times, an atom and (seesaw.core/canvas) is sufficient for this kind of thing.
Depending on how fancy you're going to get, one reason to do it in Clojure is you can extend Seesaw's protocols (selection, binding, etc) to the new widget so it works seamlessly with Seesaw. Another consideration is whether your widget needs to make use of Clojure data from other parts of the app. This will be much cleaner from Clojure than Java.
That said, if you're comfortable in Swing/Java, you can do it there and Seesaw will be perfectly happy to work with a custom widget built in Java. Good luck!
FP is good for doing UI programming but for that the underlying UI framework should also be based on FP concepts like FRP etc. In your case the underlying UI framework (Swing) is OO based and hence it would be more easy to implement it in Java but you can still do it in seesaw.
All else being equal (i.e. assuming you know both Clojure and Java), I would probably write this as a custom Swing component in Java.
Reasons:
Swing is fundamentally a Java-based OOP framework and is a better fit with Java in terms of paradigm
Mutable state is easier in Java than in Clojure
If you write it in Java, you can use it elsewhere more easily (e.g. as a library from other Java code)
It's easy to wrap a Swing component in Clojure after you have created it
Of course, for the application logic itself I would certainly prefer Clojure.
I just started using clojure today (however , I have used Java a lot and know of functional paradigms) and I was wondering if it was a good idea to build a clojure app with a reasonable complex interface (dragging, dropping, panning, zooming,...) using Swing?
I can imagine that a lot of the normal swing logics (especially concerning OO) has to be bypassed one way or the other..
I asume that all is possible , but is it possible in a way that justifyable?
I mean wouldn't it be like hitting a nail with a screwdriver in stead of with a hammer?
Has anyone here have experience in building GUI's with Clojure (and of Course : is Swing the ideal candidate for that?)
Thanks !
I've found it relatively easy to use Swing to build decent user interfaces in Clojure. You have a couple of options about how to do it however:
Write the code pretty much as you would in Java, just using the Java interop from Clojure to call the relevant Swing APIs. This article does a good job of explaining how, with a bit of macro magic as well to make your life easier.
Use a Clojure GUI wrapper for Swing, e.g. seesaw or clj-swing. My take is that these tools have the potential to help you write some really neat GUI code in idiomatic Clojure
One really cool feature of Clojure's software transactional memory subsystem is that it allows you to set watches on variables: whenever the variable is changed (by anything), your callback gets executed. This lends itself to a powerful sort of GUI programming where the GUI updates itself automagically based on the state of your variables.
A short but non-trivial Swing GUI example is described in detail at http://www.paullegato.com/blog/swing-clojure-gui-black-scholes/ .
Since others are mentioning swing related answers, I'll ask you one question: Is Swing a requirement. Although writing Swing code in clojure is more pleasant then in Java, it is still Swing, with all its verbosity and annoyances, especially in complex application with hard set requirements.
Have you considered web UI, where Clojure fits much more natural? Or SWT or QT Jambi, which also can be made to work using Clojure.
I tried out EF back in .NET 3.5 SP1, and I was one of the many who got frustrated and decided to learn LINQ to SQL instead. Now that I know EF is the "chosen" path forward, plus EF 4.0 has some exciting new features, I'd like to migrate my app to EF 4.0.
Can anyone suggest any good resources that are specifically targeted towards 4.0 and L2S migration? NOTE: I can find plenty of blogs and articles related to migrating from L2S to EF on .NET 3.5, but I feel like many of those were obviously dated and unhelpful to someone using 4.0.
I'd really like as much deep, under-the-hood stuff as I can get; I want to really come away feeling like I know EF 4.0 the way I currently know L2S 3.5.
TIA!
I have done loads of this very type of conversion and FWIW, I would say there are more similarities than differences. I don't think there is any definitive documentation that will make you feel like an expert in EF4, beyond the stuff that is already out there...
http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx
What I can give you are the more obvious "gotchas." Specifically, Linq2Sql wanted to combine the business layer and the data layer a lot more obviously. It really pushed you to create your own partial classes. I could go on and on about way, but the most specific reason is the way the one-to-one mapper will create public parent and child properties for all relations.
If you attempt to use any type of serialization against this model, you will like run into circular reference problems as a serializer moves from a parent to a child and then back to the parent as the Linq2Sql serialization behavior automatically includes all children in the graph. This can also be really annoying when you try to grab a customer record to check the "Name" property and automatically get all the related order records included in the graph. You can set these parent and child navigation properties to be either "public" or "internal" which means if you want access to them, but don't want the serializers to automatically create circular references, you pretty much have to access them in partial classes.
Once you start down the partial class path you generally just continue the pattern and eventually will start to add helper methods for accessing your data into your individual entity classes. Also, with the Linq2Sql DataContext being more lightweight, you often find people using some kind of Singleton pattern or Repository pattern for their context. You don't see this as much at all with EF 3.5 / 4.
So let's say you have some environment similar to the one described and you want to start converting. Well, you need to find out when your DataContext is going to be create/destroyed...some people will just start each Business Layer method with a using() statement and let the context pretty much live for the lifetime of the method. Obviously this means you can get into some hairy situations that require adding .ToList() or some other extension method to the ends of your questions you can have a fully in-memory collection of your objects to pass to a child method or whatever and even then you can have problems with attempting to update entities on a context that they weren't originally retrieved from.
You'll also need to figure out how to much of the BusinessLogic incorporated in your Linq2Sql partial classes out into another layer if it doesn't deal explicitly with the data operations. This will not be painless as you figure out when you need/don't need your context, but it is for the best..
Next, you will want to deal with the object graph situation. Because of the difference in the way lazy-loading works (they made this configurable in EF 4.0 to make it behave more like Linq2Sql for those who wanted it) you will probably need to check any implied uses of child objects in the graph from your Linq2Sql implementation and verify that it doesn't now require an explicit .Include() or a .Load() to get the child objects in the graph.
Finally, you will need to decide on a serialization solution in general. By default, the DataContracts and DataMember attributes that are generated as part of an EF model work great with WCF, but not at all great with the XmlSerializer used for things like old .asmx WebServices. Even in this circumstance you might be able to get away with it if you never need to serialize child objects over the wire. Since that usually isn't the case, you are going to want to move to WCF if you have a more SOA, which will add a whole new host of opportunies, yet headaches.
In order to deal with the partial classes situation, and the hefty DataContext and even the serialization issues, there are a number of new code-generation templates available with EF 4.0. The POCO-Entity template has a lot of people excited as it creates POCO classes, just as you'd expect (the trouble is that excludes any class or member attributes for WCF etc etc). Also, the Self-Tracking Entities model pretty much solves the context issue, because you can pass your entities around and let them remember when and how they were updated, so you can create/dispose your contexts much more freely (like Linq2Sql). As another bonus, this template is the go-to template for WCF or anything that builds on WCF like RIA Services or WCF Data Services, so they have the [DataContract], [DataMember], and [KnownType] attributes already figured out.
Here is a link to the POCO template (not included out of the box):
(EDIT: I cannot post two hyperlinks, so just visit the visualstudio gallery website and search for "ADO.NET C# POCO Entity Generator")
Be sure to read the link on the ADO.net team blog about implementing this. You might like the bit about splitting your context and your entities into separate projects/assemblies if you fall into the WebService vs. WCF Service category. The "Add Service Reference..." proxy generation doesn't do namespaces the same way "Add Web Reference..." used to, so you might like to actually reference your entity class assembly in your client app so you can "exclude types from reference libraries" or whatever on your service references so you don't get a lot of ambiguous references from multiple services which use the same EF model and expose those entities...
I know this is long and rambling, but these little gotchas were waaay more of an issue for me than remembering to use context.EntityCollection.AddObject() instead of context.EntityCollection.InsertOnSubmit() and context.SaveChanges() instead of context.SubmitChanges()...
For EF Code First, it's mostly about reverse engineering the existing tables into EF classes. EF Power Tools now does this for you:
http://msdn.microsoft.com/en-us/data/jj200620.aspx
The rest is the obvious work of modifying your existing code to use those generated classes to talk to the database instead of LINQ to SQL.
All the web frameworks that I have seen mostly follow the OO paradigm. Are there any web frameworks in Python or Ruby which follow the FP style?
Like python itself, you'll probably find web frameworks in python that blend the functional and object oriented paradigms. Django is a great example. Django follows a model-view-controller design, which they label as model-template-view. The interesting thing is that the three layers operate very differently.
Model is object-oriented. It isn't necessary to make it a stellar example of everything OOP can be. You can be dirt simple with your models: you name it, extend a base model class, and declare a few properties. This, I think, is as it ought to be, and I'll be fascinated to learn of other frameworks that are significantly less object-oriented at the model-layer. Your database needs table declarations, and your site needs to generate rows of data. This is extremely analagous to Classes and Instances no matter how you look at it.
Template is not python. It's supposed to look as much like html as possible, with some pretty ways to insert data that gets passed to it.
View is very functional. It can be coerced into an OO paradigm, and it can rely on the models to do the heavy lifting if it wants. But at core there are function declarations that execute some action. These function declarations are passed as arguments to a url config function.
I happen to like this blend of paradigms because I believe it does what works well for each given level. Some might call it inconsistent; others might say that the distinction between between model and presentation logic should be as sharp as possible to emphasize the distinction.
If you don't care much for OOP but can function in python, this framework might work well for you. Unless you're trying to leverage the default admin interface. Then metaclasses and formsets will make your head a'splode.