Home » Language IDEs » ServerTools (WTP) » JSP Editor
| JSP Editor [message #7235] |
Thu, 21 August 2003 12:42  |
Eclipse User |
|
|
|
Originally posted by: lopezmm.mixmail.com
It seems that this is the subproyect we should begin with.
I think there are a lot of basic jsp editors out there, and we should begin
with some base (sintax coloring, and basic autocompletion). The
autocompletion database, should read the custom tags defined in TLDs
libraries found in the proyect (or web.xml)
Then we should aim to 2 basic targets:
* Native jsp debugging (I don
|
|
| |
| Re: JSP Editor [message #7548 is a reply to message #7235] |
Fri, 22 August 2003 16:04  |
| Eclipse User |
|
|
|
Originally posted by: robert.varga.fathomtechnology.com
No, this is definitely not the stuff to begin with.
To work with JSPs you have to be able to integrate them with one another and
other
files in the project, and deploy them!
Therefore the first to do is to provide a base infrastructure that can hold
together all stuff
to be developed later.
You need to be able to manage deployment units, deployment methods and
deployment
destinations.
That is the very first thing to do.
That means that creation and management of deployment units have to be the
first.
A deployment unit is the set of files that are deployed together.
This is you have to be able to designate the future place of single files
and project subtrees
inside a deployment unit. When you have this, you know what is necessary to
be deployed together.
This is followed by the deployment methods:
- you can make export procedures for deployment units to either jar/war/ear
or exploded directory format.
- you can make deployment procedures of jar/war/ear or exploded
directory-structures into application
servers.
- you may want to integrate parts of the previous two together to directly
deploy from source to the server.
This is followed by managing deployment destinations to not to enter data
necessary to the deployment every time
you are deploying something. A deployment destination can be a Server
instance, or a Domain in a cluster.
The later two may be parallel to making the JSP editor, but the first
(deployment units) is not possible without
that, since JSP files may refer one another and to find one another, you
need the deployment units to find what
is assigned together in which places.
Just my 2cents.
Please think before you jump into development.
Regards,
Robert Varga
"Mart
|
|
| |
| Re: JSP Editor [message #7586 is a reply to message #7548] |
Sat, 23 August 2003 18:20 |
 Mike Dickson
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
I completely agree. The deployment approach will probably dictate
requirements to the other tools (like a jsp or xml descriptor editor) so
getting that nailed down first is really critical.
Mike
"Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
news:bi5et3$g4l$1@eclipse.org...
> No, this is definitely not the stuff to begin with.
>
> To work with JSPs you have to be able to integrate them with one another
and
> other
> files in the project, and deploy them!
>
> Therefore the first to do is to provide a base infrastructure that can
hold
> together all stuff
> to be developed later.
>
> You need to be able to manage deployment units, deployment methods and
> deployment
> destinations.
>
> That is the very first thing to do.
>
> That means that creation and management of deployment units have to be the
> first.
> A deployment unit is the set of files that are deployed together.
>
> This is you have to be able to designate the future place of single files
> and project subtrees
> inside a deployment unit. When you have this, you know what is necessary
to
> be deployed together.
>
> This is followed by the deployment methods:
> - you can make export procedures for deployment units to either
jar/war/ear
> or exploded directory format.
> - you can make deployment procedures of jar/war/ear or exploded
> directory-structures into application
> servers.
> - you may want to integrate parts of the previous two together to directly
> deploy from source to the server.
>
> This is followed by managing deployment destinations to not to enter data
> necessary to the deployment every time
> you are deploying something. A deployment destination can be a Server
> instance, or a Domain in a cluster.
>
> The later two may be parallel to making the JSP editor, but the first
> (deployment units) is not possible without
> that, since JSP files may refer one another and to find one another, you
> need the deployment units to find what
> is assigned together in which places.
>
> Just my 2cents.
>
> Please think before you jump into development.
>
> Regards,
>
> Robert Varga
>
>
>
>
> "Mart
|
|
| |
| Re: JSP Editor [message #7628 is a reply to message #7586] |
Sat, 23 August 2003 20:13 |
Emerson Cargnin
Messages: 125
Registered: July 2009 |
Senior Member |
|
|
Don't know if I agree completely. If someone just want to use the edit to
edit their page , without using any deployment approach provided by
webtools? I think it is the lomboz mainly problem. I don't want to install
every configuration file from lomboz (I do everything though my ant build),
just to use it's jsp editor, but I have to install everything to make my
project enabled to jsp editing, this is not good.
"Michael Dickson" <mike.dickson@earthlink.net> escreveu na mensagem
news:bi8b8k$il6$1@eclipse.org...
> I completely agree. The deployment approach will probably dictate
> requirements to the other tools (like a jsp or xml descriptor editor) so
> getting that nailed down first is really critical.
>
> Mike
>
> "Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
> news:bi5et3$g4l$1@eclipse.org...
> > No, this is definitely not the stuff to begin with.
> >
> > To work with JSPs you have to be able to integrate them with one another
> and
> > other
> > files in the project, and deploy them!
> >
> > Therefore the first to do is to provide a base infrastructure that can
> hold
> > together all stuff
> > to be developed later.
> >
> > You need to be able to manage deployment units, deployment methods and
> > deployment
> > destinations.
> >
> > That is the very first thing to do.
> >
> > That means that creation and management of deployment units have to be
the
> > first.
> > A deployment unit is the set of files that are deployed together.
> >
> > This is you have to be able to designate the future place of single
files
> > and project subtrees
> > inside a deployment unit. When you have this, you know what is necessary
> to
> > be deployed together.
> >
> > This is followed by the deployment methods:
> > - you can make export procedures for deployment units to either
> jar/war/ear
> > or exploded directory format.
> > - you can make deployment procedures of jar/war/ear or exploded
> > directory-structures into application
> > servers.
> > - you may want to integrate parts of the previous two together to
directly
> > deploy from source to the server.
> >
> > This is followed by managing deployment destinations to not to enter
data
> > necessary to the deployment every time
> > you are deploying something. A deployment destination can be a Server
> > instance, or a Domain in a cluster.
> >
> > The later two may be parallel to making the JSP editor, but the first
> > (deployment units) is not possible without
> > that, since JSP files may refer one another and to find one another, you
> > need the deployment units to find what
> > is assigned together in which places.
> >
> > Just my 2cents.
> >
> > Please think before you jump into development.
> >
> > Regards,
> >
> > Robert Varga
> >
> >
> >
> >
> > "Mart
|
|
|
| Re: JSP Editor [message #7649 is a reply to message #7628] |
Sat, 23 August 2003 22:28 |
Joss Wright
Messages: 32
Registered: July 2009 |
Member |
|
|
I'm not sure I agree with deployment either, yes it is an issue but is it
a dependancy. When I built the Webapp Plugin, I considered deployment, in
most circumstances to be production deployment, I know it's not completely
the case but that's what I believed. My main focus was on development how
do I develop and where should I develop, I came up with the following
requirements:
1. I should be able to use any editor, XML, text, external.
2. I should have a rapid development cycle, i.e. write some code, run
it/debug it, re-edit it, possibly without actually deploying it.
3. I should be able to run my code in any make AND any version of web
application server.
4. I should be able to configure the server for different scenarios, e.g.
edit container managed authentication as necessary.
So when I developed the Webapp Plugin I kept most of this in mind:
1. It does matter which editor you use, this may/will make a difference
for JSP debugging but I can use my favourite editor.
2. A web application project is not deployed to a web server, the server
is configured to run the project from the workspace. Yes it requires an
intimate understanding of the server, i.e. it is not a generic deployment
process but specific to each server but all web servers I've so far
implemented I can configure the context 'working directory'. This means if
I alter a file in the project it does not need a manual or automatic
redeployment, in fact with JS files the server just recompiles it.
3. I created an adapter architecture that allows multiple makes and
versions of a web app server to be plugged into Eclipse. The architecture
does dictate how a server has to be launched, i.e. it can be launched as a
separate VM or as an embedded server. Also the classes for the server can
be external, i.e. point to a pre-installed server outside of Eclipse, or
internal the necessary jars are provided as a plugin to Eclipse.
4. The plugin has a .servers project in the workspace, that contains the
configuration files for each server. The config files at present are
edited via a text editor but in the long run they could have a
configuration interface added, although the interface would be specific to
each server.
So I believe the project should be broken into areas that can be developed
independantly of each other, i.e. editors, server
configuration/launching/debugging, production deployment, wizards etc.
However where depandancies are likely then identify them early but still
work in parallel.
Just my 2p worth, you may/may not agree.
Regards,
Joss
Emerson Cargnin wrote:
> Don't know if I agree completely. If someone just want to use the edit to
> edit their page , without using any deployment approach provided by
> webtools? I think it is the lomboz mainly problem. I don't want to install
> every configuration file from lomboz (I do everything though my ant build),
> just to use it's jsp editor, but I have to install everything to make my
> project enabled to jsp editing, this is not good.
> "Michael Dickson" <mike.dickson@earthlink.net> escreveu na mensagem
> news:bi8b8k$il6$1@eclipse.org...
> > I completely agree. The deployment approach will probably dictate
> > requirements to the other tools (like a jsp or xml descriptor editor) so
> > getting that nailed down first is really critical.
> >
> > Mike
> >
> > "Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
> > news:bi5et3$g4l$1@eclipse.org...
> > > No, this is definitely not the stuff to begin with.
> > >
> > > To work with JSPs you have to be able to integrate them with one another
> > and
> > > other
> > > files in the project, and deploy them!
> > >
> > > Therefore the first to do is to provide a base infrastructure that can
> > hold
> > > together all stuff
> > > to be developed later.
> > >
> > > You need to be able to manage deployment units, deployment methods and
> > > deployment
> > > destinations.
> > >
> > > That is the very first thing to do.
> > >
> > > That means that creation and management of deployment units have to be
> the
> > > first.
> > > A deployment unit is the set of files that are deployed together.
> > >
> > > This is you have to be able to designate the future place of single
> files
> > > and project subtrees
> > > inside a deployment unit. When you have this, you know what is necessary
> > to
> > > be deployed together.
> > >
> > > This is followed by the deployment methods:
> > > - you can make export procedures for deployment units to either
> > jar/war/ear
> > > or exploded directory format.
> > > - you can make deployment procedures of jar/war/ear or exploded
> > > directory-structures into application
> > > servers.
> > > - you may want to integrate parts of the previous two together to
> directly
> > > deploy from source to the server.
> > >
> > > This is followed by managing deployment destinations to not to enter
> data
> > > necessary to the deployment every time
> > > you are deploying something. A deployment destination can be a Server
> > > instance, or a Domain in a cluster.
> > >
> > > The later two may be parallel to making the JSP editor, but the first
> > > (deployment units) is not possible without
> > > that, since JSP files may refer one another and to find one another, you
> > > need the deployment units to find what
> > > is assigned together in which places.
> > >
> > > Just my 2cents.
> > >
> > > Please think before you jump into development.
> > >
> > > Regards,
> > >
> > > Robert Varga
> > >
> > >
> > >
> > >
> > > "Martín López" <lopezmm@mixmail.com> wrote in message
> > > news:bi2eke$ntb$1@eclipse.org...
> > > > It seems that this is the subproyect we should begin with.
> > > > I think there are a lot of basic jsp editors out there, and we should
> > > begin
> > > > with some base (sintax coloring, and basic autocompletion). The
> > > > autocompletion database, should read the custom tags defined in TLDs
> > > > libraries found in the proyect (or web.xml)
> > > > Then we should aim to 2 basic targets:
> > > > * Native jsp debugging (I donŽt know too much, but it seems that this
> > > issue
> > > > is VERY difficult)
> > > > * Visual Design & Preview
> > > > For the second one, I think it should be based on GEF. Somebody has
> > worked
> > > > with GEF previously?
> > > > Another issue is the outline preview, like xml buddyŽs, but it should
> > have
> > > > icons for every jsp/html tag.
> > > > What do you think?
> > > >
> > > >
> > >
> > >
> >
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
|
|
|
| Re: JSP Editor [message #7670 is a reply to message #7548] |
Sun, 24 August 2003 07:23 |
| Eclipse User |
|
|
|
Originally posted by: IVKPUB.HOTMAIL.COM
"Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
news:bi5et3$g4l$1@eclipse.org...
> No, this is definitely not the stuff to begin with.
>
> To work with JSPs you have to be able to integrate them with one another
and
> other
> files in the project, and deploy them!
>
> Therefore the first to do is to provide a base infrastructure that can
hold
> together all stuff
> to be developed later.
>
There are at least three areas in the web development - modeling, deployment
and general purpose tools.
The latter includes full featured XML Editor that could be used as a
foundation for XSLT, XHTML, JSP, descriptors and <you_name_ it> editors.
These editors are in high demand in the Eclipse community and will be in use
immediately.
(Frankly, I do not understand how come that XML Editor is not yet a
"standard" Eclipse editor like Text Editor ).
These components are general purpose tools and they have minimum dependency
on any other components.
All they need is ability to resolve references to external resources ( DTD,
TLD etc ) not only by static configurations ( preferences ) but also by
supporting some kind of resource locator interface.
For instance, JSP editor can get access to referenced TLD with something
like:
getProjectAdapter( project, JSP_NATURE ).locate( base, tldUri );
If no such adapter can be found then the editor will use its default
resource resolving policy
( looking for "WEB-INF", using local/global preferences setting etc ).
Therefore we can start "general tools" subprojects immediately
just keeping in mind that they have to support dynamic configurations.
Deployment tools should handle more responsibility than just deploying
application
on some specific server environment.
They are bridges between modeling abstractions and real word things, aka.
target platforms.
Let's refer to them as to platform adapters.
These adapters will wrap all platform specific details and allow developers
to launch and debug an application without the actual deployment ( in
place ).
Finally they should be able to build and pack the application into
deployment packages (EAR, WAR ).
I would not agree that deployment framework could play a role as "a base
infrastructure that can hold together all stuff". That is where model
manager comes to play.
Model manager provides DeploymentContent for the deployment tools.
For instance, one can decide to deploy static resources ( images/ binary
files etc )
on HTTP server ( or FTP ) and servlets on JSP container.
That requires to create two DeploymentContent for two platform adapters,HTTP
and JSP.
Platform adapters should provide some meta information that could be used
for DeploymentContent creation..
For example,
- types of container ( HTTP, JSP, EJB ).
- a list of valid resource types for the platform configuration they
represent.
( *.jsp is not a valid resource type for JSP container that runs on JRE,
therefore does not support JSP compilation.)
Modeling tools accommodate higher level of abstractions related to the web
development.
Modeling tools have to be based on a core model that will be used to
implement a set of data patterns, behavioral patterns and related templates.
There is a simple primer - form. Let's assume we have defined a pattern
FORM.
It has data structures that hold all field's properties ( label, value type,
description etc).
It has also link to the form's view element ( jsp or servlet )
This pattern also has defined a set of actions - prepare data, prepare view,
validate input, if ok then do this else do that.
Then we select menu item "generate" and, if template set is not yet
assigned,
we select a named template set, let's say, "Struts".
As a result we will have generated form-bean and action-mapping in
struts-config.xml,
form in validator.xml, fields' labels in application.properties and a set of
java classes
derived from Action ( or from a custom class ) as stubs to implement form
related actions.
EMF would be a right choice for the modeling tools, but it seems it's not
quite suitable
for activity modeling. At least, EMF would be used as a pattern to follow.
Regards,
Igor Khlystov
|
|
|
| Re: JSP Editor / deploy managemement [message #7691 is a reply to message #7670] |
Sun, 24 August 2003 12:39 |
Emerson Cargnin
Messages: 125
Registered: July 2009 |
Senior Member |
|
|
the deployer could be already JSR88 and JSR77based, since they are required
features of j2ee 1.4
<copied from="http://www.jcp.org/en/jsr/detail?id=88">
2.1 Please describe the proposed Specification:
This specification defines standard APIs that will enable any deployment
tool that uses the deployment APIs to deploy any assembled application onto
a J2EE compatible platform.
The API will address the three-stage deployment process:
a.. Installation - move the properly packaged components to the server
b.. Configuration - the resolution of all external dependencies declared
by the application
c.. Undeployment - removal of the application from the server
</copied>
<copied from="http://www.jcp.org/en/jsr/detail?id=77">
2.1 Please describe the proposed Specification:
The Specification proposes a standard management model for exposing and
accessing the management information, operations, and parameters of the Java
2 Platform, Enterprise Edition components. The management model will:
a.. Allow rapid development of management solutions for J2EE
b.. Provide integration with existing management systems
c.. Enable a single management tool to manage multiple vendor
implementations of the platform
d.. Enable a specific implementation of a platform to use any compliant
management tool
</copied>
just for ilustration :
http://ishmael.forge.objectweb.org/ishmael-overview.pdf
http://www.javaworld.com/javaworld/jw-06-2002/jw-0614-mgmt.h tml
http://www.jcp.org/en/jsr/detail?id=88
"Igor Khlystov" <IVKPUB@HOTMAIL.COM> escreveu na mensagem
news:bi9p24$btv$1@eclipse.org...
> "Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
> news:bi5et3$g4l$1@eclipse.org...
> > No, this is definitely not the stuff to begin with.
> >
> > To work with JSPs you have to be able to integrate them with one another
> and
> > other
> > files in the project, and deploy them!
> >
> > Therefore the first to do is to provide a base infrastructure that can
> hold
> > together all stuff
> > to be developed later.
> >
>
> There are at least three areas in the web development - modeling,
deployment
> and general purpose tools.
>
>
>
> The latter includes full featured XML Editor that could be used as a
> foundation for XSLT, XHTML, JSP, descriptors and <you_name_ it> editors.
>
> These editors are in high demand in the Eclipse community and will be in
use
> immediately.
>
> (Frankly, I do not understand how come that XML Editor is not yet a
> "standard" Eclipse editor like Text Editor ).
>
>
>
> These components are general purpose tools and they have minimum
dependency
> on any other components.
>
> All they need is ability to resolve references to external resources (
DTD,
> TLD etc ) not only by static configurations ( preferences ) but also by
> supporting some kind of resource locator interface.
>
>
>
> For instance, JSP editor can get access to referenced TLD with something
> like:
>
> getProjectAdapter( project, JSP_NATURE ).locate( base, tldUri );
>
> If no such adapter can be found then the editor will use its default
> resource resolving policy
>
> ( looking for "WEB-INF", using local/global preferences setting etc ).
>
>
>
> Therefore we can start "general tools" subprojects immediately
>
> just keeping in mind that they have to support dynamic configurations.
>
>
>
>
>
> Deployment tools should handle more responsibility than just deploying
> application
>
> on some specific server environment.
>
> They are bridges between modeling abstractions and real word things, aka.
> target platforms.
>
> Let's refer to them as to platform adapters.
>
>
>
> These adapters will wrap all platform specific details and allow
developers
>
> to launch and debug an application without the actual deployment ( in
> place ).
>
> Finally they should be able to build and pack the application into
> deployment packages (EAR, WAR ).
>
>
>
> I would not agree that deployment framework could play a role as "a base
> infrastructure that can hold together all stuff". That is where model
> manager comes to play.
>
> Model manager provides DeploymentContent for the deployment tools.
>
> For instance, one can decide to deploy static resources ( images/ binary
> files etc )
>
> on HTTP server ( or FTP ) and servlets on JSP container.
>
> That requires to create two DeploymentContent for two platform
adapters,HTTP
> and JSP.
>
>
>
> Platform adapters should provide some meta information that could be used
> for DeploymentContent creation..
>
> For example,
>
> - types of container ( HTTP, JSP, EJB ).
>
> - a list of valid resource types for the platform configuration they
> represent.
>
> ( *.jsp is not a valid resource type for JSP container that runs on JRE,
> therefore does not support JSP compilation.)
>
>
>
> Modeling tools accommodate higher level of abstractions related to the web
> development.
>
> Modeling tools have to be based on a core model that will be used to
> implement a set of data patterns, behavioral patterns and related
templates.
>
>
>
> There is a simple primer - form. Let's assume we have defined a pattern
> FORM.
>
> It has data structures that hold all field's properties ( label, value
type,
> description etc).
>
> It has also link to the form's view element ( jsp or servlet )
>
> This pattern also has defined a set of actions - prepare data, prepare
view,
>
> validate input, if ok then do this else do that.
>
> Then we select menu item "generate" and, if template set is not yet
> assigned,
>
> we select a named template set, let's say, "Struts".
>
>
>
> As a result we will have generated form-bean and action-mapping in
> struts-config.xml,
>
> form in validator.xml, fields' labels in application.properties and a set
of
> java classes
>
> derived from Action ( or from a custom class ) as stubs to implement form
> related actions.
>
>
>
> EMF would be a right choice for the modeling tools, but it seems it's not
> quite suitable
>
> for activity modeling. At least, EMF would be used as a pattern to
follow.
>
>
>
> Regards,
>
> Igor Khlystov
>
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
|
|
|
| Re: JSP Editor [message #7758 is a reply to message #7649] |
Wed, 27 August 2003 09:13 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Ideas in the night: DevWiki and the Eclipse Web Tools Platform project
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.
One of my 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.
-Avery Regier
JossWright wrote:
> I'm not sure I agree with deployment either, yes it is an issue but is it
> a dependancy. When I built the Webapp Plugin, I considered deployment, in
> most circumstances to be production deployment, I know it's not completely
> the case but that's what I believed. My main focus was on development how
> do I develop and where should I develop, I came up with the following
> requirements:
>
> 1. I should be able to use any editor, XML, text, external.
> 2. I should have a rapid development cycle, i.e. write some code, run
> it/debug it, re-edit it, possibly without actually deploying it.
> 3. I should be able to run my code in any make AND any version of web
> application server.
> 4. I should be able to configure the server for different scenarios, e.g.
> edit container managed authentication as necessary.
>
>
> So when I developed the Webapp Plugin I kept most of this in mind:
>
> 1. It does matter which editor you use, this may/will make a difference
> for JSP debugging but I can use my favourite editor.
>
> 2. A web application project is not deployed to a web server, the server
> is configured to run the project from the workspace. Yes it requires an
> intimate understanding of the server, i.e. it is not a generic deployment
> process but specific to each server but all web servers I've so far
> implemented I can configure the context 'working directory'. This means if
> I alter a file in the project it does not need a manual or automatic
> redeployment, in fact with JS files the server just recompiles it.
>
> 3. I created an adapter architecture that allows multiple makes and
> versions of a web app server to be plugged into Eclipse. The architecture
> does dictate how a server has to be launched, i.e. it can be launched as a
> separate VM or as an embedded server. Also the classes for the server can
> be external, i.e. point to a pre-installed server outside of Eclipse, or
> internal the necessary jars are provided as a plugin to Eclipse.
>
> 4. The plugin has a .servers project in the workspace, that contains the
> configuration files for each server. The config files at present are
> edited via a text editor but in the long run they could have a
> configuration interface added, although the interface would be specific to
> each server.
>
> So I believe the project should be broken into areas that can be developed
> independantly of each other, i.e. editors, server
> configuration/launching/debugging, production deployment, wizards etc.
>
> However where depandancies are likely then identify them early but still
> work in parallel.
>
> Just my 2p worth, you may/may not agree.
>
> Regards,
>
> Joss
>
>
>
>
> Emerson Cargnin wrote:
>
>
>>Don't know if I agree completely. If someone just want to use the edit to
>>edit their page , without using any deployment approach provided by
>>webtools? I think it is the lomboz mainly problem. I don't want to install
>>every configuration file from lomboz (I do everything though my ant build),
>>just to use it's jsp editor, but I have to install everything to make my
>>project enabled to jsp editing, this is not good.
>
>
>
>>"Michael Dickson" <mike.dickson@earthlink.net> escreveu na mensagem
>>news:bi8b8k$il6$1@eclipse.org...
>>
>>>I completely agree. The deployment approach will probably dictate
>>>requirements to the other tools (like a jsp or xml descriptor editor) so
>>>getting that nailed down first is really critical.
>>>
>>>Mike
>>>
>>>"Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
>>>news:bi5et3$g4l$1@eclipse.org...
>>>
>>>>No, this is definitely not the stuff to begin with.
>>>>
>>>>To work with JSPs you have to be able to integrate them with one another
>>>
>>>and
>>>
>>>>other
>>>>files in the project, and deploy them!
>>>>
>>>>Therefore the first to do is to provide a base infrastructure that can
>>>
>>>hold
>>>
>>>>together all stuff
>>>>to be developed later.
>>>>
>>>>You need to be able to manage deployment units, deployment methods and
>>>>deployment
>>>>destinations.
>>>>
>>>>That is the very first thing to do.
>>>>
>>>>That means that creation and management of deployment units have to be
>>
>>the
>>
>>>>first.
>>>>A deployment unit is the set of files that are deployed together.
>>>>
>>>>This is you have to be able to designate the future place of single
>>
>>files
>>
>>>>and project subtrees
>>>>inside a deployment unit. When you have this, you know what is necessary
>>>
>>>to
>>>
>>>>be deployed together.
>>>>
>>>>This is followed by the deployment methods:
>>>>- you can make export procedures for deployment units to either
>>>
>>>jar/war/ear
>>>
>>>>or exploded directory format.
>>>>- you can make deployment procedures of jar/war/ear or exploded
>>>>directory-structures into application
>>>>servers.
>>>>- you may want to integrate parts of the previous two together to
>>
>>directly
>>
>>>>deploy from source to the server.
>>>>
>>>>This is followed by managing deployment destinations to not to enter
>>
>>data
>>
>>>>necessary to the deployment every time
>>>>you are deploying something. A deployment destination can be a Server
>>>>instance, or a Domain in a cluster.
>>>>
>>>>The later two may be parallel to making the JSP editor, but the first
>>>>(deployment units) is not possible without
>>>>that, since JSP files may refer one another and to find one another, you
>>>>need the deployment units to find what
>>>>is assigned together in which places.
>>>>
>>>>Just my 2cents.
>>>>
>>>>Please think before you jump into development.
>>>>
>>>>Regards,
>>>>
>>>>Robert Varga
>>>>
>>>>
>>>>
>>>>
>>>>"Martín López" <lopezmm@mixmail.com> wrote in message
>>>>news:bi2eke$ntb$1@eclipse.org...
>>>>
>>>>>It seems that this is the subproyect we should begin with.
>>>>>I think there are a lot of basic jsp editors out there, and we should
>>>>
>>>>begin
>>>>
>>>>>with some base (sintax coloring, and basic autocompletion). The
>>>>>autocompletion database, should read the custom tags defined in TLDs
>>>>>libraries found in the proyect (or web.xml)
>>>>>Then we should aim to 2 basic targets:
>>>>>* Native jsp debugging (I donŽt know too much, but it seems that this
>>>>
>>>>issue
>>>>
>>>>>is VERY difficult)
>>>>>* Visual Design & Preview
>>>>>For the second one, I think it should be based on GEF. Somebody has
>>>
>>>worked
>>>
>>>>>with GEF previously?
>>>>>Another issue is the outline preview, like xml buddyŽs, but it should
>>>
>>>have
>>>
>>>>>icons for every jsp/html tag.
>>>>>What do you think?
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>>---
>>Outgoing mail is certified Virus Free.
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
>
>
>
|
|
|
| Re: JSP Editor [message #7842 is a reply to message #7758] |
Thu, 28 August 2003 13:41 |
| Eclipse User |
|
|
|
Originally posted by: robert.varga.fathomtechnology.com
<user@domain.invalid> wrote in message news:bihsm4$1si$1@eclipse.org...
> ...
> 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.
You also be able to resolve references by <%@ include and <%@ forward
into the project itself. You would possibly like to support other internal
references
as well, such as struts actions and tiles descriptors. That also needs a
general way.
> 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.
That's why I suggested to invent the management of deployment units, which
would describe
a logical tree, where parts of the project tree would land in a deployment
unit.
Eg. project folder mydocroot/ would land in the document root for web files,
class files from a utility classes source folder would land under
WEB-INF/classes,
and so on.
Robert Rarga
> ...
>
> -Avery Regier
>
> JossWright wrote:
>> ...
....
|
|
|
| Re: JSP Editor [message #7863 is a reply to message #7842] |
Thu, 28 August 2003 13:51 |
| Eclipse User |
|
|
|
Originally posted by: robert.varga.fathomtechnology.com
"Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
news:bil0pl$76c$1@eclipse.org...
>
> <user@domain.invalid> wrote in message news:bihsm4$1si$1@eclipse.org...
> > ...
> > 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.
>
> You also be able to resolve references by <%@ include and <%@ forward
This of course wanted to be <jsp:forward instead of <%@ forward.
Sorry for the mistake.
Robert Varga
|
|
|
| Re: JSP Editor [message #7884 is a reply to message #7670] |
Thu, 28 August 2003 14:57 |
| Eclipse User |
|
|
|
Originally posted by: robert.varga.fathomtechnology.com
"Igor Khlystov" <IVKPUB@HOTMAIL.COM> wrote in message
news:bi9p24$btv$1@eclipse.org...
> "Robert Varga" <robert.varga@fathomtechnology.com> wrote in message
> news:bi5et3$g4l$1@eclipse.org...
> > No, this is definitely not the stuff to begin with.
> >
> > To work with JSPs you have to be able to integrate them with one another
> and
> > other
> > files in the project, and deploy them!
> >
> > Therefore the first to do is to provide a base infrastructure that can
> hold
> > together all stuff
> > to be developed later.
> >
>
> There are at least three areas in the web development - modeling,
deployment
> and general purpose tools.
>
>
>
> The latter includes full featured XML Editor that could be used as a
> foundation for XSLT, XHTML, JSP, descriptors and <you_name_ it> editors.
>
> These editors are in high demand in the Eclipse community and will be in
use
> immediately.
>
> (Frankly, I do not understand how come that XML Editor is not yet a
> "standard" Eclipse editor like Text Editor ).
>
I agree, this is an almost independent feature, and could be quite welcome.
However,
a facility is needed in Eclipse (if it is not already there), to retrieve
resources based on an
URI, into which projects can also register resources (e.g. SCHEMAs referring
on another schema
in a user project should be resolvable by this facility).
>
>
> These components are general purpose tools and they have minimum
dependency
> on any other components.
>
> All they need is ability to resolve references to external resources (
DTD,
> TLD etc ) not only by static configurations ( preferences ) but also by
> supporting some kind of resource locator interface.
>
>
Agreed.
>
> For instance, JSP editor can get access to referenced TLD with something
> like:
>
> getProjectAdapter( project, JSP_NATURE ).locate( base, tldUri );
>
> If no such adapter can be found then the editor will use its default
> resource resolving policy
>
> ( looking for "WEB-INF", using local/global preferences setting etc ).
>
>
TLD-s are resolvable this way. However included resources are not necessary.
A JSP file can reference other JSP files, included JSP snippets, and other
files,
and also other abstractions or references such as Struts actions and Tiles
descriptors.
Some of these are not necessary resolvable by a central registry, or may not
be the
best thing to resolve through a central registry. Some of this is better to
be resolved by
the deployment unit management, such as relative references on a file to be
%@ include-d
or jsp:include-ed.
>
> Therefore we can start "general tools" subprojects immediately
>
> just keeping in mind that they have to support dynamic configurations.
>
No, first it should be agreed on how to resolve the references to a
resource.
Afterwards can all things which depend only on this be started.
>
>
>
>
> Deployment tools should handle more responsibility than just deploying
> application
>
> on some specific server environment.
>
> They are bridges between modeling abstractions and real word things, aka.
> target platforms.
>
> Let's refer to them as to platform adapters.
>
>
No comments on this.
>
> These adapters will wrap all platform specific details and allow
developers
>
> to launch and debug an application without the actual deployment ( in
> place ).
>
No, debugging should never take place without the intended deployment
environment.
There may always be bugs in the deployment environment (the application
server), which
causes problems, and without the actual environment used, we would be faced
with bugs
which we cannot reproduce, since they are caused by the environment itself.
> Finally they should be able to build and pack the application into
> deployment packages (EAR, WAR ).
>
>
EAR-s and WAR-s are supposed to be standard (appserver-independent) formats.
As long as that assumption is correct,
it is not the responsibility of the platform adapter to build them.
If the EARs and WARs are platform-specific, the differences of course they
may be added by platform adapters, from information
retrieved from the project and the info on the deployment units.
>
> I would not agree that deployment framework could play a role as "a base
> infrastructure that can hold together all stuff". That is where model
> manager comes to play.
>
I did not say that the deployment framework would hold together all stuff. I
said the
deployment unit management would hold together all stuff. The is constrained
only to describe
the place of project files in the logical tree of all files to be deployed.
This logical tree can then be split up
into one or more archive files to be deployed into.
> Model manager provides DeploymentContent for the deployment tools.
>
> For instance, one can decide to deploy static resources ( images/ binary
> files etc )
>
> on HTTP server ( or FTP ) and servlets on JSP container.
>
> That requires to create two DeploymentContent for two platform
adapters,HTTP
> and JSP.
>
>
How I imaged that thing is the following. Let's suppose we have a project
called Project.
Let's suppose it contains 5 folders (not important how many):
- WebFolder
- EJBFolder
- src
- lib
- bin
- dist
Webfolder contains three folders:
- images: static files served possibly even served by a HTTP-only server
- pages: jsp files to be served by an appserver
- misc: other files, not to be deployed in current form, info to generate
stuff from, and so on...
src folder contains Java source of Servlets, tag classes, struts actions and
stuff.
lib folder contains libraries you use in your webapp (classes generated from
src and EJBFolder excluded).
bin folder is where src is compiled to by JDT.
dist is the folder where EJBFolder is compiled and its stuff is generated to
for example by XDoclet.
Deployment unit management should cover how these get into one or more
archive (JAR/WAR/EAR) files.
I envisioned it that you specify the place of project elements in a logical
tree, e.g. the following way
(example tree only):
DeploymentUnit
\-- Static
\-- EJBs
\-- Dynamic
\---- WEB-INF
\---- classes
\---- lib
An assignment is designated the following way:
Project Element -----> Logical tree node
means that the place of 'Project Element' should be 'Logical tree node' in
the logical tree, and everything under it
should form a separate structure. If an assignment is made from under
Project element, then that overrides everything
above it. (Assignments are resolved starting from the leaves, meaning the
future place in the logical tree of a file is determined
by the innermost assignment enclosing it).
Now let's say we have a deployment unit (the logical tree) called
DeploymentUnit. and let's say, the folllowing assignments are
made between project elements and nodes in the deployment unit logical tree:
Project/WebFolder/images -----> DeploymentUnit/Static
Project/WebFolder/pages -----> DeploymentUnit/Dynamic
Project/bin -----> DeploymentUnit/Dynamic/WEB-INF/classes
Project/lib -----> DeploymentUnit/Dynamic/WEB-INF/lib
Project/dist -----> DeploymentUnit/EJBs
Conflict of overlap between project elements are reported as an error, and
until resolved, those parts are not deployable.
E.g. it would be an error, if a WebFolder/pages/WEB-INF/classes existed,
because then it could not be determined,
where a DeploymentUnit/Dynamic/WEB-INF/classes comes from, since it may have
come both from Project/bin or
Project/WebFolder/pages/WEB-INF/classes.
This is a unit which is not having any dependencies to any other things.
We may designate certain nodes as having special properties, such as
DeploymentUnit/Dynamic being a
web component and DeploymentUnit/EJBs being an EJB component. Component
meant in a sense as
being a bunch of files to be deployed together in one archive.
We could also designate DeploymentUnit/Dynamic and DeploymentUnit/EJBs
together forming an Application.
Now let's say, that we want to deploy this deployment unit into archives.
That is already the responsibility of deployment itself. It is
not having any relevance to internal references.
Let's suppose that we want
DeploymentUnit/Dynamic to be grouped together in a WAR file called web.war.
DeploymentUnit/EJBs to be grouped together to a JAR file called ejbs.jar.
web.war and ejbs.war are grouped together into an EAR file called
application.ear
That is the archive creation process.
Now let's suppose we want that application.ear file to be deployed to an
application server.
We also want DeploymentUnit/Static to be deployed to a Web server directly,
with FTP.
But we could also want to make a deployment to an application server
directly from
the Application grouping together DeploymentUnit/Dynamic and
DeploymentUnit/EJBs.
That is the are of deployment methods. Deployment methods should be capable
of reading
a (possibly specifically designated) part of the Deploment Unit's logical
tree, or an archive
of appropriate kind instead, and deploy them to a specific kind of server.
Each of these would
need an adapter.
Possible list of adapters, and what they would be capable of deploying in
what form:
- FTP, SFTP, RSYNC, WEBDAV, FileCopy adapters deploying subtree structures
or archive files into an exploded directory format on the appropriate
destination.
- application server adapters being able to deploy appropriate components
into the application
servers (e.g. a Weblogic adapter capable of deploying EJB components, web
components, complete
applications either from the matching archive format (EJB JAR, WAR, EAR in
matcing order), or
on-the-fly from the source of the designated parts of the logical tree
(e.g. deploying DeploymentUnit/EJBs which is designated to be an EJB
component on the fly)
>
> Platform adapters should provide some meta information that could be used
> for DeploymentContent creation..
>
> For example,
>
> - types of container ( HTTP, JSP, EJB ).
>
> - a list of valid resource types for the platform configuration they
> represent.
>
> ( *.jsp is not a valid resource type for JSP container that runs on JRE,
> therefore does not support JSP compilation.)
>
See previous section of my answer.
>
>
> Modeling tools accommodate higher level of abstractions related to the web
> development.
>
> Modeling tools have to be based on a core model that will be used to
> implement a set of data patterns, behavioral patterns and related
templates.
>
>
>
> There is a simple primer - form. Let's assume we have defined a pattern
> FORM.
>
> It has data structures that hold all field's properties ( label, value
type,
> description etc).
>
> It has also link to the form's view element ( jsp or servlet )
>
> This pattern also has defined a set of actions - prepare data, prepare
view,
>
> validate input, if ok then do this else do that.
>
> Then we select menu item "generate" and, if template set is not yet
> assigned,
>
> we select a named template set, let's say, "Struts".
>
>
>
> As a result we will have generated form-bean and action-mapping in
> struts-config.xml,
>
> form in validator.xml, fields' labels in application.properties and a set
of
> java classes
>
> derived from Action ( or from a custom class ) as stubs to implement form
> related actions.
>
>
Let's not try to reinvent the wheel. First let's see, whether we could not
integrate
xdoclet, which does the exact same things. Of course it may not be possible,
and these are not too big tasks to implement alone. However if we found a
generic
way to integrate xdoclet into the compile mechanism, that would be a huge
boon.
>
> EMF would be a right choice for the modeling tools, but it seems it's not
> quite suitable
>
> for activity modeling. At least, EMF would be used as a pattern to
follow.
>
>
I don't know EMF enough to comment upon.
>
> Regards,
>
> Igor Khlystov
>
>
>
>
Regards,
Robert Varga
|
|
|
| Re: JSP Editor [message #9281 is a reply to message #7607] |
Thu, 16 October 2003 17:06 |
| Eclipse User |
|
|
|
Originally posted by: daniel787.lycos.com
Does anybody know where can I find out the latest information regarding
the status of the JSP editor for eclipse?
Regards
DP
Darin Swanson wrote:
> I believe you are talking about
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=25798
> Darins
> "Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
> news:bi7jjb$3be$1@eclipse.org...
> > > * Native jsp debugging (I donŽt know too much, but it seems that this
> > issue
> > > is VERY difficult)
> > I don't know the state of this work but I know that the debug team
> > worked on that implementing a wellknown JSR.
> > You should be able to find info in the eclipse-dev mailing list
> archive
> >
> > PaScaL
> >
> >
|
|
|
| Re: JSP Editor [message #12195 is a reply to message #7235] |
Mon, 15 December 2003 06:18 |
Ali Demir
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Rather than editor and deployment tools, I suggest this project starts with
a site creation tool where the site developer visually creates a tree
representing a site structure where each node is a page on the browser.
Then each Node will be represented by a parametrized template such that a
developer should be able to logically group these nodes and make them
members of logical groups. For example group A, group B, group C pages. Then
the developer should be able to write parametrized java code or html or do
visual design on a group basis (write code that applies to all pages in
group A, in a paratmetric way, which means when final jsp is generated, the
code for page 1 is not the same as page 2 even though they are both in group
A and code was specified only once but it effected n number of pages in
group A).
For example, developer should be able to visually say group A pages display
child pages on their left side. Then this Eclipse tool should store that
info for the Node and when compiled, it should generate correct html/jsp
code to display child pages, whatever they might be, on the left. Or
developer should be able to write code that says "display parent page name
here" and tell our tool to apply this code to all group B pages and the
exact name of the parent page would depend on the location of the node in
the website hierarchy.
This site structure tool should be designed such that it should be possible
to write jsp code for individual nodes (pages) such that if pages are moved
around, code need not be touched, or can be automatically updated by the
site wizard.
We should also provide visual representation of files included into other
files etc. Developer should also be able to include a file on the exact
relative location of all pages in a given page group. Again the included
file should be able to contain paratmetrized code such that it's contents
can mean one thing for page 1 and another for page 2 and something else for
page 3, yet the content should always be valid. In other words, developer
should be able to say, "Here is some code in file X that displays a banner
with the page title on it. I want this file to be included to all pages of
group A such that it displays the banner with the correct page title of the
page it was included into."
Taking this parametric approach visual design and coding efforts for
individual pages can be minimized.
Anyway, if you have any questions, drop me a line.
Suavi Demir
demir4@yahoo.com
"Mart
|
|
|
Goto Forum:
Current Time: Sat Nov 09 05:48:46 GMT 2024
Powered by FUDForum. Page generated in 0.04121 seconds |
] 
Search
Help
Register
Login
Home
