Thread: [Hypercontent-developer] HyperContent 2.0 status
Brought to you by:
alexvigdor
Menu
▾
▴
hypercontent-developer
|
From: Alex V. <av...@co...> - 2004-09-02 16:52:29
|
Hello all, I just wanted to provide a status update on the development of HyperContent 2.0. As of last night, I have created a new CVS module "hypercontent2" which contains the current code and library dependencies for HyperContent 2. This is very much a work in progress; there are no build scripts currently, and I have not checked in any project content to demonstrate the new server. The way to run HyperContent 2 is through a new class, "org.hypercontent.HTTPServer", which uses Tomcat in embedded mode to offer up the server. HyperContent 2 is backwards compatible with version 1.x projects, but the structure has changed: project definition files now reside within the project repository, at "/config/project-definition.xml", and another file "/config/permissions.xml" is used to configure permissions. I will check in sample content in the near future. A quick overview of what is there already in the HyperContent 2.0 code base: a standalone web server using JAAS for authentication, which can serve up static or processed data via "pipelines", and supports advanced browser caching via the HTTP1.1 specification, including support for If-Modified-Since and Etag headers, as well as the basic Last-Modified, Content-Length and Content-Type headers. Projects are mapped to base paths within the servlet context, so that the URL of a file looks something like "http://www.server.edu/hypercontent-servlet/project-mapping/file-dir/ file.ext". Recursive dependency resolution has been implemented, so for example a file which is transformed by an XSL stylesheet which imports another XSL file will be properly recognized as out-of-date if the imported XSL file is changed. Disk caching has been implemented using Berkeley DB Java Edition, so that dynamic processing of a page is only performed once after server startup, until any dependency of that page is modified. As of right now, HyperContent 2 can act as a dynamic web server for any HyperContent 1.x project content. HyperContent 1.x style batch processing has not yet been migrated over, but will be soon. HyperContent 2.0 is introducing a new type of view, which I've taken to calling "modal". Any form of content presentation that was supported under HyperContent 1.x is considered a "static" view, such that it is mapped to a plain URL, and is a candidate for batch processing and disk caching. Modal views of content will be mapped to a "mode" parameter in addition to the basic URL, and will not be capable of being built in a batch request or cached to disk - they are exclusively dynamic. This type of view will be used for management and authoring tools. I am currently working on integrating the Velocity templating engine as an alternative to XSLT, and with either templating language you will be able to import other modal views, such that modal views can be assembled as components and brought together in various combinations. For example, a directory browser will be a single component that might be reused in different contexts, such as a 1.x style management screen, or in an "open file" dialog that might pop-up when you want to insert an image in a WYSIWYG area. We're still a few weeks off from doing an alpha release, but the code is now out there if anyone is interested in taking a peek. I'll be happy to help anyone with further details on the migration process, as needed. Cheers, Alex |
|
From: Jack P. <jac...@gm...> - 2004-09-02 17:10:20
|
Thanks Alex. I plan to look at the code in terms of adding a topic map as a navigational system to the architecture. It's pretty clear I'll need to ask a few questions along the way. The first one is: how soon a build.xml? Many thanks. Jack On Thu, 2 Sep 2004 12:52:37 -0400, Alex Vigdor <av...@co...> wrote: > Hello all, > I just wanted to provide a status update on the development of > HyperContent 2.0. As of last night, I have created a new CVS module > "hypercontent2" which contains the current code and library > dependencies for HyperContent 2. This is very much a work in progress; > there are no build scripts currently, and I have not checked in any > project content to demonstrate the new server. > The way to run HyperContent 2 is through a new class, > "org.hypercontent.HTTPServer", which uses Tomcat in embedded mode to > offer up the server. HyperContent 2 is backwards compatible with > version 1.x projects, but the structure has changed: project definition > files now reside within the project repository, at > "/config/project-definition.xml", and another file > "/config/permissions.xml" is used to configure permissions. I will > check in sample content in the near future. > > A quick overview of what is there already in the HyperContent 2.0 code > base: a standalone web server using JAAS for authentication, which can > serve up static or processed data via "pipelines", and supports > advanced browser caching via the HTTP1.1 specification, including > support for If-Modified-Since and Etag headers, as well as the basic > Last-Modified, Content-Length and Content-Type headers. Projects are > mapped to base paths within the servlet context, so that the URL of a > file looks something like > "http://www.server.edu/hypercontent-servlet/project-mapping/file-dir/ > file.ext". Recursive dependency resolution has been implemented, so for > example a file which is transformed by an XSL stylesheet which imports > another XSL file will be properly recognized as out-of-date if the > imported XSL file is changed. Disk caching has been implemented using > Berkeley DB Java Edition, so that dynamic processing of a page is only > performed once after server startup, until any dependency of that page > is modified. As of right now, HyperContent 2 can act as a dynamic web > server for any HyperContent 1.x project content. HyperContent 1.x style > batch processing has not yet been migrated over, but will be soon. > > HyperContent 2.0 is introducing a new type of view, which I've taken to > calling "modal". Any form of content presentation that was supported > under HyperContent 1.x is considered a "static" view, such that it is > mapped to a plain URL, and is a candidate for batch processing and disk > caching. Modal views of content will be mapped to a "mode" parameter > in addition to the basic URL, and will not be capable of being built in > a batch request or cached to disk - they are exclusively dynamic. This > type of view will be used for management and authoring tools. I am > currently working on integrating the Velocity templating engine as an > alternative to XSLT, and with either templating language you will be > able to import other modal views, such that modal views can be > assembled as components and brought together in various combinations. > For example, a directory browser will be a single component that might > be reused in different contexts, such as a 1.x style management screen, > or in an "open file" dialog that might pop-up when you want to insert > an image in a WYSIWYG area. > > We're still a few weeks off from doing an alpha release, but the code > is now out there if anyone is interested in taking a peek. I'll be > happy to help anyone with further details on the migration process, as > needed. > > Cheers, > Alex > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Hypercontent-developer mailing list > Hyp...@li... > https://lists.sourceforge.net/lists/listinfo/hypercontent-developer > |
|
From: Alex V. <av...@co...> - 2004-09-02 17:31:15
|
Jack, Depending exactly what you intend to do, I might recommend implementing it in HyperContent 1.4. Are you specifically interested in generating a topic map for a web site to be managed in HyperContent? If so, you could accomplish that in the current release and fairly painlessly migrate it into 2.0 down the road. HyperContent supports RDF metadata; you could implement topics in the Dublin Core Subject field (no Java coding required), or you could develop a small editor to manage a custom topic metadata grammar (some Java coding required, to a well defined API which will unfortunately be changing a bit in v2). Producing the topical map could then be implemented as a combination of XML includes and XSL processing to group related materials together. HyperContent's design allows you to implement quite complex, custom web site features with little to no Java coding, once you grok the power of XML includes combined with XSLT. The XML Includes allow you to pull all data and/or metadata out of your repository into a single XML document for XSL processing. Alex On Sep 2, 2004, at 1:10 PM, Jack Park wrote: > Thanks Alex. > > I plan to look at the code in terms of adding a topic map as a > navigational system to the architecture. It's pretty clear I'll need > to ask a few questions along the way. > > The first one is: how soon a build.xml? > > Many thanks. > Jack > > On Thu, 2 Sep 2004 12:52:37 -0400, Alex Vigdor <av...@co...> > wrote: >> Hello all, >> I just wanted to provide a status update on the development of >> HyperContent 2.0. As of last night, I have created a new CVS module >> "hypercontent2" which contains the current code and library >> dependencies for HyperContent 2. This is very much a work in >> progress; >> there are no build scripts currently, and I have not checked in any >> project content to demonstrate the new server. >> The way to run HyperContent 2 is through a new class, >> "org.hypercontent.HTTPServer", which uses Tomcat in embedded mode to >> offer up the server. HyperContent 2 is backwards compatible with >> version 1.x projects, but the structure has changed: project >> definition >> files now reside within the project repository, at >> "/config/project-definition.xml", and another file >> "/config/permissions.xml" is used to configure permissions. I will >> check in sample content in the near future. >> >> A quick overview of what is there already in the HyperContent 2.0 code >> base: a standalone web server using JAAS for authentication, which >> can >> serve up static or processed data via "pipelines", and supports >> advanced browser caching via the HTTP1.1 specification, including >> support for If-Modified-Since and Etag headers, as well as the basic >> Last-Modified, Content-Length and Content-Type headers. Projects are >> mapped to base paths within the servlet context, so that the URL of a >> file looks something like >> "http://www.server.edu/hypercontent-servlet/project-mapping/file-dir/ >> file.ext". Recursive dependency resolution has been implemented, so >> for >> example a file which is transformed by an XSL stylesheet which imports >> another XSL file will be properly recognized as out-of-date if the >> imported XSL file is changed. Disk caching has been implemented using >> Berkeley DB Java Edition, so that dynamic processing of a page is only >> performed once after server startup, until any dependency of that page >> is modified. As of right now, HyperContent 2 can act as a dynamic web >> server for any HyperContent 1.x project content. HyperContent 1.x >> style >> batch processing has not yet been migrated over, but will be soon. >> >> HyperContent 2.0 is introducing a new type of view, which I've taken >> to >> calling "modal". Any form of content presentation that was supported >> under HyperContent 1.x is considered a "static" view, such that it is >> mapped to a plain URL, and is a candidate for batch processing and >> disk >> caching. Modal views of content will be mapped to a "mode" parameter >> in addition to the basic URL, and will not be capable of being built >> in >> a batch request or cached to disk - they are exclusively dynamic. >> This >> type of view will be used for management and authoring tools. I am >> currently working on integrating the Velocity templating engine as an >> alternative to XSLT, and with either templating language you will be >> able to import other modal views, such that modal views can be >> assembled as components and brought together in various combinations. >> For example, a directory browser will be a single component that might >> be reused in different contexts, such as a 1.x style management >> screen, >> or in an "open file" dialog that might pop-up when you want to insert >> an image in a WYSIWYG area. >> >> We're still a few weeks off from doing an alpha release, but the code >> is now out there if anyone is interested in taking a peek. I'll be >> happy to help anyone with further details on the migration process, as >> needed. >> >> Cheers, >> Alex >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >> _______________________________________________ >> Hypercontent-developer mailing list >> Hyp...@li... >> https://lists.sourceforge.net/lists/listinfo/hypercontent-developer >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Hypercontent-developer mailing list > Hyp...@li... > https://lists.sourceforge.net/lists/listinfo/hypercontent-developer > |
|
From: Jack P. <jac...@gm...> - 2004-09-02 17:50:11
|
Thanks, Alex. My thinking is that I have a need that goes beyond uPortal, so I thought I'd start with standalone HyperContent, meaning 2.0. I suppose there is some benefit, however, in starting with 1.4 I'll look at it. Particularly, I'll try to come up to speed on the editors you mention. I suspect, however, that there are some requirements for a topic map engine, quite possibly TM4J, though TM4J would need to be integrated with the backside used in HyperContent. I have a few ideas of my own on knowledge datastores, and will need to think all this through in the context of HyperContent. Thanks Jack On Thu, 2 Sep 2004 13:31:23 -0400, Alex Vigdor <av...@co...> wrote: > Jack, > Depending exactly what you intend to do, I might recommend > implementing it in HyperContent 1.4. Are you specifically interested > in generating a topic map for a web site to be managed in HyperContent? > If so, you could accomplish that in the current release and fairly > painlessly migrate it into 2.0 down the road. HyperContent supports > RDF metadata; you could implement topics in the Dublin Core Subject > field (no Java coding required), or you could develop a small editor to > manage a custom topic metadata grammar (some Java coding required, to a > well defined API which will unfortunately be changing a bit in v2). > Producing the topical map could then be implemented as a combination of > XML includes and XSL processing to group related materials together. > HyperContent's design allows you to implement quite complex, custom web > site features with little to no Java coding, once you grok the power of > XML includes combined with XSLT. The XML Includes allow you to pull > all data and/or metadata out of your repository into a single XML > document for XSL processing. > > Alex > > > > On Sep 2, 2004, at 1:10 PM, Jack Park wrote: > > > Thanks Alex. > > > > I plan to look at the code in terms of adding a topic map as a > > navigational system to the architecture. It's pretty clear I'll need > > to ask a few questions along the way. > > > > The first one is: how soon a build.xml? > > > > Many thanks. > > Jack > > |
|
From: Alex V. <av...@co...> - 2004-09-02 18:43:31
|
Jack, I guess the level of integration will depend on the use cases to be satisfied. If you'd like to allow people to manage topic maps, which could then be published to a web site, an editor would provide you the appropriate "space" within which to plug the appropriate engine and a GUI for manipulating the data. This would assume that the ultimate persisted representation would be XML, which could then be transformed using XSL or another templating language, and would work well enough under 1.4. If you envision a more dynamic interaction with a separate topic store, HyperContent 2.0 introduces a class hierarchy of FileAssets, which may represent some processing on top of whatever data exists in the repository file. I use this to dynamically generate Navigation structures from template files, but it could also be used to dynamically build an XTM document from a separate store upon request (e.g. page render time). If you'd like to present topic maps as a means of finding data in the repository, HyperContent 2.0 will definitely be a more appropriate environment, as the management environment in v1.x is monolithic, allowing plug-ins only at the level of editing particular files, not for navigating the system. The use of modal views in 2.0 will allow for a much more customizable management experience. Cheers, Alex On Sep 2, 2004, at 1:50 PM, Jack Park wrote: > Thanks, Alex. > > My thinking is that I have a need that goes beyond uPortal, so I > thought I'd start with standalone HyperContent, meaning 2.0. > > I suppose there is some benefit, however, in starting with 1.4 > > I'll look at it. Particularly, I'll try to come up to speed on the > editors you mention. I suspect, however, that there are some > requirements for a topic map engine, quite possibly TM4J, though TM4J > would need to be integrated with the backside used in HyperContent. I > have a few ideas of my own on knowledge datastores, and will need to > think all this through in the context of HyperContent. > > Thanks > Jack > > On Thu, 2 Sep 2004 13:31:23 -0400, Alex Vigdor <av...@co...> > wrote: >> Jack, >> Depending exactly what you intend to do, I might recommend >> implementing it in HyperContent 1.4. Are you specifically interested >> in generating a topic map for a web site to be managed in >> HyperContent? >> If so, you could accomplish that in the current release and fairly >> painlessly migrate it into 2.0 down the road. HyperContent supports >> RDF metadata; you could implement topics in the Dublin Core Subject >> field (no Java coding required), or you could develop a small editor >> to >> manage a custom topic metadata grammar (some Java coding required, to >> a >> well defined API which will unfortunately be changing a bit in v2). >> Producing the topical map could then be implemented as a combination >> of >> XML includes and XSL processing to group related materials together. >> HyperContent's design allows you to implement quite complex, custom >> web >> site features with little to no Java coding, once you grok the power >> of >> XML includes combined with XSLT. The XML Includes allow you to pull >> all data and/or metadata out of your repository into a single XML >> document for XSL processing. >> >> Alex >> >> >> >> On Sep 2, 2004, at 1:10 PM, Jack Park wrote: >> >>> Thanks Alex. >>> >>> I plan to look at the code in terms of adding a topic map as a >>> navigational system to the architecture. It's pretty clear I'll need >>> to ask a few questions along the way. >>> >>> The first one is: how soon a build.xml? >>> >>> Many thanks. >>> Jack >>> > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Hypercontent-developer mailing list > Hyp...@li... > https://lists.sourceforge.net/lists/listinfo/hypercontent-developer > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X