This post originated from an RSS feed registered with Java Buzz
by Avery Regier.
Original Post: Ideas in the night: DevWiki and the Eclipse Web Tools Platform project
Feed Title: cAVEman's Musings
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Musings of Avery Regier on the subject of Java, DevWiki, J2EE, Java operating systems, and whatever else strikes my fancy.
My wife woke me up at about 3:30 this morning so that we could look at
Mars. Now I can't get to sleep because my brain keeps thinking up
ideas.
The first one is for DevWiki.
We need to have an IncludePageTranslator that will allow you to include
some other wiki page inline in the current one. This would be
useful for table of contents like pages where you have headings
followed by content for that heading. If you went to a page just
for that heading, then you would get just the bullets for that
heading. This would be very nice for organizing
documentation. Incidentally, it would provide a workaround to
allow you create tables within tables with the simple TableTranslator
markup.
My other ideas this night are for how to add a generic JSP editor to Eclipse for the Eclipse Web Tools Platform Project.
I haven't been involved in the project yet, so I'm sure at least to a
certain degree these ideas are already there in one form or
another. One of the main issues with writing a JSP editor is that
in order to do code assist
and to validate the contents of a JSP you must be able to find the
context of a JSP. Without these two features a JSP editor is just
something that has been color coded for you. There are plenty of
those, we need a an editor that will help us build the JSP code.
For instance, you need to find, load and parse the web.xml file in
order to find all of your .tld files. Then you need to parse the
.tld's to find individual tags and attributes. The problem is
that every application server tends to be different. The ways
that people want to set up a web application project will tend to be
different too. We have a specification for how to put together a
.war file, but that doesn't mean those files will be in exactly those
locations in the project you are editing. I don't want to
restrict how projects are set up just so that the JSP editor can be
used, because I may want a very different setup than someone else will
be comfortable with. My company may have different standards or
deployment environments that dictate how certain things should
be. Further, I may want to have a base project that holds
standard content or setup for a web application that gets aggregated
with the contents of my project to get the full contents of the
deployable web application. So I may want to have two web.xml
files: one with standard tag library definitions, mime types, etc, and
the other with my applications servlet definitions and mappings.
At compile, debug, and deployment times, I'd then want to aggregate
these two files together to present to the app server.
Thus I propose that you want (at least) two levels of plugin extension
points that your standard JSP editor relies on. The level that
the JSP editor would directly rely on is one that finds resources for
you. For instance, it would have a method to get all of the tag
libraries accessible to the current jsp. It would also have
a method that when passed a path to an included JSP file would present
that file. Eclipse does provide a way to discover an
implementation of a particular extension point. A standard
implementation of these extension points would simply follow the servlet
and JSP specifications in a simplistic way to discover these
files. It would assume a single web.xml with no aggregation and a
project in .war file format. It could then have an extension
point that simple asks for configuration information such as what the
context root is and where the document root and WEB-INF directories can
be found. This presents the opportunity to write an advanced
implementation of the JSP editor's extension that would aggregate the
contents of the application from muliple sources. A plugin such
as the Sysdeo Tomcat plugin could easily implement the basic
configuration information extension point.
Previous Topic
