I'm looking forward to seeing your tool in action! It's about time we have an open-source screenplay writing tool. I have some request for features. Do you have a features list kept somewhere that I can look at? Should I post my requests here or into Feature Tracker?
I might also be interested in helping, but I won't have any time until beginning of 2003. At worst, maybe I can help integrate my features when your application is at a state that can allow it.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. Feature Tracker is a good place to post requests; mailing lists work too, but ideas are less likely to be forgotten in the Feature Tracker. For deeper feature discussion (especially comparisons with existing proucts), I'd refer you to the writersforge-plot mailing list. As far as I'm concerned, the more discussion the better!
The nearest thing to a features list right now is my TODO file. I just put a link to it from the home page, under Project Info. As the project matures, the feature list will grow more concrete. It's still in the very early infrastructure stages....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok! I'll add my thoughts into the feature tracker. I will mention 1 or 2 here just for some light discussion.
I imagine taking what we've learned from collaborative software development and applying it to screenplay writing. For example, it would be great to have multiple people working on the same script at the same time... using a version control like system to help manage it.
If 1/2 of the application is an editor (does all the typical stuff an editor would do), could we start with an open source editor (like JEdit), and with slight modification of the core (maybe) and plugins, etc make it work for us? It seems like having a full blown plugin architecture and editor already developed could get the project farther and have development concentrating on only the things that make it required for script writing.
These are some of my thoughts... I'd be interested in hearing your thoughts on these items.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those are some good ideas. The collaboration idea strikes to the heart of one of my long term goals. I'd like to be able to "host" a screenplay environment on a server, with logins, live chats, and concurrent writing.
My first attempt to support this was a generic Storage API, but I've since learned that JDO offers this plus much more, so I've switched gears. Also, EJB support is critical to the collaborative idea (JSP would be way too clunky for that).
My initial screenplay XML format includes support for revisions, and I believe it's very important to support both revisions and annotations -- especially with collaboration.
I thought about "borrowing" bits of existing Java editors like JEdit and NetBeans, but in both cases the architecture of those apps was too complex and heavyweight. I'm very much a minimalist, and am very stingy with required dependencies. Plus, the cost of learning and adapting existing editors seemed to be about the same as writing a small, specialized editor.
A lot of these issues will be simplified by my work on RenderForge. RF was originally just a PDF generation wrapper, but it has grown in scope to serve many fundamental purposes. It's still PDF/ASCII/HTML, but a new twist is using it as a Java source code generator. The plan is to have a single data-model XML file drive the creation of DTDs, XSDs, SQL DDLs, as well as boilerplate JavaBean code, JDO/JDBC, Java/XML bindings, EJB, and even Swing GUI code. There are a lot of code generation tools out there already, but none with such scope, driven from a single XML file. (See the TODO link from the home page for more details.)
So, when all of that is in place (hopefully by X-mas), creating and extending a screenwriting application becomes very simple. Want an EJB version? Just tweak your Ant script and rebuild. Customize behavoir by extending base classes.
Thanks for your comments so far!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<snip>
The plan is to have a single data-model XML file drive the creation of DTDs, XSDs, SQL DDLs, as well as boilerplate JavaBean code, JDO/JDBC, Java/XML bindings, EJB, and even Swing GUI code.
</snip>
Sounds like an interesting tool. Have you gotten to the point where one can represent Swing GUI code in XML?
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Catalan library, with a little help from Jakarta's Velocity template toolkit, can now function as a nice little code generator. I'm currently using it to bulk-generate simple unit tests for W3C XML conformance (see the project news). This is driven by an XML file supplied with the test suite that lists the name of each test, the XML file for that test, and a few other details.
So, it's currently possible to generate Java code directly from XML. There's also beginning support for generating code from SQL DDL (see Catalan release 0.1.1). Unfortunately I haven't updated the user guide with the new code generation stuff yet. As soon as I do I'll cut a 0.1.2 release.
Anyway, once Catalan 0.1.2 comes out, you'll be able to create arbitrary Velocity templates for whatever source code you want. Velocity is pretty straightforward. Using the XPath-like Bellows query language, you can iterate over different combinations of XML elements. See examples at:
The xmlconf-* files in Bellows (plus the Ant task 'build-xmlconf-tests' in the build.xml file) are all I use to create the W3C unit test suites. The files in the Catalan directory show how to create a simple JavaBean data model from an SQL CREATE TABLE definition.
Like I said, docs are coming soon, but until then, feel free to ask questions in this forum or better yet on the developers' mailing list. I'd be happy to discuss features and get more feedback.
Thanks for the comments!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the detailed response. However, I think I may have phrased the question the wrong way. Instead of generating <snip>Swing code</code>, what I really meant was the ability to encapsulate Swing component and dependency definitions within an XML file, and be able to read and construct such components and their dependencies at run-time.
An example would be to define a 'form' composed of different components, store that form's template definition in an XML file, and later reconstuct the form based on the template. Does this make sense?
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, so you want to be able to create a single generic Swing container class that can dynamically load its contents from an XML file? You might use the same form class for creating many different forms. Right?
In this case, you could probably throw something together pretty easy with just Bellows and some generic Swing code. You could store all your forms in a single XML file, or break 'em up one form per file. Either way is easy with Bellows. You'd just change your Bellows Query path. So the query "forms/form[@id=myform]" would grab the second form below (hopefully the XML will come through):
The <form> element could contain nested elements for embedded Swing components. Then you can use DatumBrowser static methods to extract attribute data, e.g., getIntegerProperty().
I don't have currently anything like that for WritersForge (especially now, since I'm leaning towards using SWT and Eclipse), but it should be easy to put together with Bellows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm looking forward to seeing your tool in action! It's about time we have an open-source screenplay writing tool. I have some request for features. Do you have a features list kept somewhere that I can look at? Should I post my requests here or into Feature Tracker?
I might also be interested in helping, but I won't have any time until beginning of 2003. At worst, maybe I can help integrate my features when your application is at a state that can allow it.
Thanks!
Thanks. Feature Tracker is a good place to post requests; mailing lists work too, but ideas are less likely to be forgotten in the Feature Tracker. For deeper feature discussion (especially comparisons with existing proucts), I'd refer you to the writersforge-plot mailing list. As far as I'm concerned, the more discussion the better!
The nearest thing to a features list right now is my TODO file. I just put a link to it from the home page, under Project Info. As the project matures, the feature list will grow more concrete. It's still in the very early infrastructure stages....
Ok! I'll add my thoughts into the feature tracker. I will mention 1 or 2 here just for some light discussion.
I imagine taking what we've learned from collaborative software development and applying it to screenplay writing. For example, it would be great to have multiple people working on the same script at the same time... using a version control like system to help manage it.
If 1/2 of the application is an editor (does all the typical stuff an editor would do), could we start with an open source editor (like JEdit), and with slight modification of the core (maybe) and plugins, etc make it work for us? It seems like having a full blown plugin architecture and editor already developed could get the project farther and have development concentrating on only the things that make it required for script writing.
These are some of my thoughts... I'd be interested in hearing your thoughts on these items.
Those are some good ideas. The collaboration idea strikes to the heart of one of my long term goals. I'd like to be able to "host" a screenplay environment on a server, with logins, live chats, and concurrent writing.
My first attempt to support this was a generic Storage API, but I've since learned that JDO offers this plus much more, so I've switched gears. Also, EJB support is critical to the collaborative idea (JSP would be way too clunky for that).
My initial screenplay XML format includes support for revisions, and I believe it's very important to support both revisions and annotations -- especially with collaboration.
I thought about "borrowing" bits of existing Java editors like JEdit and NetBeans, but in both cases the architecture of those apps was too complex and heavyweight. I'm very much a minimalist, and am very stingy with required dependencies. Plus, the cost of learning and adapting existing editors seemed to be about the same as writing a small, specialized editor.
A lot of these issues will be simplified by my work on RenderForge. RF was originally just a PDF generation wrapper, but it has grown in scope to serve many fundamental purposes. It's still PDF/ASCII/HTML, but a new twist is using it as a Java source code generator. The plan is to have a single data-model XML file drive the creation of DTDs, XSDs, SQL DDLs, as well as boilerplate JavaBean code, JDO/JDBC, Java/XML bindings, EJB, and even Swing GUI code. There are a lot of code generation tools out there already, but none with such scope, driven from a single XML file. (See the TODO link from the home page for more details.)
So, when all of that is in place (hopefully by X-mas), creating and extending a screenwriting application becomes very simple. Want an EJB version? Just tweak your Ant script and rebuild. Customize behavoir by extending base classes.
Thanks for your comments so far!
<snip>
The plan is to have a single data-model XML file drive the creation of DTDs, XSDs, SQL DDLs, as well as boilerplate JavaBean code, JDO/JDBC, Java/XML bindings, EJB, and even Swing GUI code.
</snip>
Sounds like an interesting tool. Have you gotten to the point where one can represent Swing GUI code in XML?
Eric
Yes and No.
The Catalan library, with a little help from Jakarta's Velocity template toolkit, can now function as a nice little code generator. I'm currently using it to bulk-generate simple unit tests for W3C XML conformance (see the project news). This is driven by an XML file supplied with the test suite that lists the name of each test, the XML file for that test, and a few other details.
So, it's currently possible to generate Java code directly from XML. There's also beginning support for generating code from SQL DDL (see Catalan release 0.1.1). Unfortunately I haven't updated the user guide with the new code generation stuff yet. As soon as I do I'll cut a 0.1.2 release.
Anyway, once Catalan 0.1.2 comes out, you'll be able to create arbitrary Velocity templates for whatever source code you want. Velocity is pretty straightforward. Using the XPath-like Bellows query language, you can iterate over different combinations of XML elements. See examples at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/writersforge/bellows/xml/
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/writersforge/catalan/xml/transforms/
The xmlconf-* files in Bellows (plus the Ant task 'build-xmlconf-tests' in the build.xml file) are all I use to create the W3C unit test suites. The files in the Catalan directory show how to create a simple JavaBean data model from an SQL CREATE TABLE definition.
Like I said, docs are coming soon, but until then, feel free to ask questions in this forum or better yet on the developers' mailing list. I'd be happy to discuss features and get more feedback.
Thanks for the comments!
Thanks for the detailed response. However, I think I may have phrased the question the wrong way. Instead of generating <snip>Swing code</code>, what I really meant was the ability to encapsulate Swing component and dependency definitions within an XML file, and be able to read and construct such components and their dependencies at run-time.
An example would be to define a 'form' composed of different components, store that form's template definition in an XML file, and later reconstuct the form based on the template. Does this make sense?
Eric
Okay, so you want to be able to create a single generic Swing container class that can dynamically load its contents from an XML file? You might use the same form class for creating many different forms. Right?
In this case, you could probably throw something together pretty easy with just Bellows and some generic Swing code. You could store all your forms in a single XML file, or break 'em up one form per file. Either way is easy with Bellows. You'd just change your Bellows Query path. So the query "forms/form[@id=myform]" would grab the second form below (hopefully the XML will come through):
<forms>
<form id="otherform"/>
<form id="myform"/>
</forms>
The <form> element could contain nested elements for embedded Swing components. Then you can use DatumBrowser static methods to extract attribute data, e.g., getIntegerProperty().
I don't have currently anything like that for WritersForge (especially now, since I'm leaning towards using SWT and Eclipse), but it should be easy to put together with Bellows.