Open Source Alternative to Dreamweaver's .LBI?

An anonymous reader asks: "I have recently started using Dreamweaver to manage one of many websites that I work on. One feature that I am growing to love is the ability to use Dreamweaver library files (.LBI). What are Slashdot readers' opinions on this format? Is there something better (read: free and standards-compliant)? I also would like to find something I could use on an open-source platform so that I won't be locked in to using Dreamweaver. What do you use for your sites?"

Comments

Re:3 things

[pbox]

Correction: "Any real self respecting geek with a loth of time on her/his/its hands managing the egosite or at most a few more sites writes the html and css in the raw."

3 things-Frameworks.

[Anonymous Coward]

Real websites use frameworks and CMS, and only use toys like dreamweaver for playing "what if".

Re:Informative

[I_Love_Pocky!]

Some times you don't have access to server side solutions (home pages on a public server you don' t control for instance). Other times you could do a server side solution, but the processing overhead is unwanted. If you are statically sharing the same bit of HTML on multiple pages why use SSI or PHP?

They make the server do the work every single time a user views a page, instead of one time before the page is uploaded to the server.

For the programmers out there, this is analogous to doing something at run-time that could have been done at complie-time.

If you need dynamic behavior, by all means use PHP, but if your pages are static, it is a terrible waste of time. Of course, if your server does not have to deal with much of a load then it doesn't matter (better hope /. doesn't link to it).

If I understand what LBI files are...Odd man out.

[Anonymous Coward]

Makefiles would appear to be part of the solution. Combine that with CVS, CMS, and frameworks, and one can do a great deal. Linux specifically, and OSS in general does thing DIFFERENTLY, not necessarily better or worse, just different. Maybe what we need is more transition documents showing how one would do something in an open source way, as compared to the closed source way. That would go a long way towards dispelling these "OSS is inferior" posts we see all over Slashdot.

Re:templates != dreamweaver

[AnamanFan]

My reference to templetes is just Dreamweaver's templates. Yes, there are many ways in which to incorperate your own templates that will work just the way you decribed.

However, sad as it may be, a lot of web developers do not even know what xslt or even css is, let alone use it well. Nor is anyone willing to learn them. I would ventuer that the poster of the article is no different.

At the end of the day, WYSIWYG tools are what win, not hand coding. What ever the tools do to make the final product is fine for web developers, no matter what the means were to get there.

not a flame!!

[nege]

To be totally honest- I try to use vi whenever i can. reasons:

- If you code something in a dreamweaver like app, it tends to add other junk to the code - like ^M at the end of every line, and also messes up any spacing you had.

- The ability to use some of the mapping in vi allows you to make changes to the html much faster (even the use of the . command has made coding groups of things much much quicker than copy and paste, in my opinion)

At first...VI sucked. Now I really dont want to do any programming / html without it. (commands, macros, regex, oh my!!) :)
Happy html'ing.

Homegrown lbi-based template engine...

[Bazzargh]

We actually use the lbi/dwt format as the basis for our template engine. I wrote this because I was annoyed at seeing the assets the web designer works on thrown away, or at best cut & paste, into JSP solutions (the same goes for most other template solutions).

This solution works best on design-led, rather than code-led projects; ie websites not webapps, since you'll have to change and prototype the UI more, which is where DW is strong.

Unfortunately I can't at present open source my work, but here's some technical details:

• our sites static skins are built to be navigable, so that replacing URLs is enough to get the site to use the correct servlets.
  
• we ship a .war with the 'static site' skin held separately (typically under apache, see bit on URL rewriting below)
  
• the .war is configured with the url to the root of the 'static site', and its location on disk.
  
• whenever a .htm, .dwt, .lbi is requested in the dynamic site it reads it from its cache or disk, with some parts of the site replaced (see below).
  
• jsps can use static assets as templates, via a template tag lib almost the same as the struts tiles tags. This is the typical means for replacing parts of pages in the static site.
  
• the parser for the DW4 type stuff (no javascript expressions) was written by hand; for DWMX I wrote a small javacc parser for the javascript subset they support. The syntax is described pretty well in the DW help, for the JS bits you'd need to see the ECMAScript manual (or just get hold of Moz Rhino)
  
• We parse the DW comments, the 9 URL attributes in html (8 standard html4 ones + 'background' I think), and URLs in @imported styles. We parse the URLs because we rewrite them to have the full path in the 'dynamic' site + session ids. Editable regions, URLs and LibraryItems are all replaceable by configuring the .war.
  
• lbis are processed as includes; only the editable regions of files based on dwts come from that file - the rest comes from the dwt. This means you can edit the dwt files on the fly.
  
• one reason for replacing URLs is that templated JSPs can be reusing a template at a different 'depth' than the original page; putting in absolute URLs avoids this problem. A second reason is that we point all URLs in templates that arent handled by the dynamic site back to the static site - so JPGs etc are served by Apache not the J2EE server (I know there are other solutions for this involving more Apache config...)
  
• for those times you need popups - and would think you need URLs in your javascript - the no-JS-friendly [a href="x" target="y" onclick="window.open(this.href, this.target, ..."] allows URLs used by JS to be replaced.
  

It works pretty well, and its acceptably fast (when I originally wrote it on an 800MHz laptop, pages with 5 lbi includes were served in about 0.2s if they needed to be reparsed, 0.025s from the cache; for JSPs with 'tiles' tags the figures were 12s and 0.02s. ie, you don't lose much speed if you use the cache, and the first view time - important in sales demos - was much quicker than JSP. NB other template engines that don't involve the compiler are similarly fast, eg Velocity. I didn't have to work particularly hard on optimizing it as it very quickly dropped below the level where DB access and network lag dominated again.

In terms of effort, it took one developer (me) about a week over it for the first delivery for DW4; the javascripty bits and changes to the parser after DWMX came out took about 2 more.

Again, its horses for courses. For web /applications/ (where its more important to have reusable UI components) stuff like Tapestry is a better fit. If you are uncomfortable writing parsers, this project is not for you. If you are comfortable with Velocity, then there are velocity extensions for DW that may suit. However, for all our website work this template engine fits our workflow like a glove.

Re:templates != dreamweaver

[Anonymous Coward]

At the end of the day, WYSIWYG tools are what win, not hand coding.

Unfortunately, HTML isn't WYSIWYG. HTML is WYSISYGUTCC (under the current configuration). In my experience, this can be problematic if someone else uses a different browser/fonts/resolution than you do. When you consider this problem, it really makes more sense to know exactly what is going on under the covers.