Hi,

> Stylesheets::
> I dont know who is writing the midgard manual/tutorial now, but after working
> with a few sites, we came to the conclusion that the 'infered' way of working
> with styles was not really that effective.

Experience speaks volumes and with 2.0 in the design phase, this is an
important time to examine the Style system.

I don't use DreamWeaver or any similar tool so I'm pretty limited in my
experience. Of course, many people use these types of tools and if
we want Midgard to be useful to these people, we'll have to examine the
problem of integrating generated html into the Style system.

I am not a Midgard core developer so I am to be considered with that
disclaimer. As I see this issue, there's nothing that documentation can do
to clarify the integration of generated html with the Style system.

Emile has considered solutions for this problem but hasn't
identified a WYSIWYG publishing tool that definitively addresses the
problem of integrating in a way that takes advantage of the Style system.
Is the solution to integrate a tool into Midgard, build an integrated tool
find a way to export, edit and import the generated html? I'm not capable
of answering the question. Sorry!

My study of the Style system has been applied to a Record label, parent
style, with many artists, inherited child styles. I haven't integrated the
inherited child styles on the artist pages but this should be easy enough.
This would be a good time to turn theory into an applied
solution, I've just got to find time. The inherited child styles
combined with SiteGroups, in theory, creates a managable environment.

The record label parent Style was modeled from VMUC. I've got a CSS
included in the head blah blah. The main parent table was generated with a
tool, don't know which one, I modified the main table by stripping out all
the formating tags.

I guess this is where your frustration applies, how to edit this
table/element and the inheritable style-elements with independent tools.
This hasn't been a problem for me, yet, because I'm happy with what I've
got. When I want changes I use a text editor. Obviously, this isn't a
solution that applies to everybody or even to every web that I will
design.

I'm told that Aurora has a GPL Java editor laying around, developed in
house. I've asked about the tool but haven't recieved any useful
responses. I know other people have looked at available tools that could
be integrated but nothing has ever come from these efforts.

I'm certain that Aurora isn't going to invest resources into an integrated
Style editing solution for 1.4. I think they're right in this
decision. Aurora is attempting to invest in 2.0 which will extend
Midgard beyound it's Publishing capabilities by making it a Content
Management system. My guess on a time frame for a 2.0 that users can
install and begin running, the developers might disagree with me entirely,
six months. 2.0 will replace 1.4 so the addition of an extended Style
editing tool should be designed for integration into 2.0. This applies to
any tools on the user interface layer, I guess.

If 1.4 is going to compete with E-Grail in the Style management
realm, we'll need to develope the solution independently of Aurora. 

The documentation that we're producing at Aurora has little to do with end
users. It's aimed at prospective users, it's a combination of a Marketing
and Technical White Paper. The new administration site should be delivered
in about a week. Considering Aurora's plan and schedule, I am not sure
we'll have time to write a user's perspective for the admin site. This
will have to be done independently of Aurora. I would be happy to
participate in writing this documentation but if I continue working for
Aurora, I believe my assignment will focus on 2.0.

It's imperative to Aurora's interest that we begin focusing on 2.0. I
believe it's equally important for Midgard's medium and long term
interests to begin focusing on a 2.0 that is a Content Management
system for any type of project. Make no mistake about it, the change of
focus from 1.4 to 2.0 means that what we have 30 days from now is
what we'll have to work with for the next six months. My opinion!

We will have a significantly improved administration site. Repligard has
been promised to the user community but to my knowledge it is not being
worked on. Repligard is the only Midgard feature to which I have any
contentions with Aurora's influence and effort. I believe we've promised
the tool and that we should deliver some type of solution. My best
capacity to ascertain the 2.0 features leads me to believe that
replication will be an inherint feature of the storage backend (LDAP???).
This means implementing more robust 2.0 replication solution will be less
work than than implementing limited Replication in 1.4. There
are no plans within Aurora to improve the Style system or integrate an
editing tool.

The developers who built 1.4 are either no longer working on Midgard or
they've been hired by Aurora to complete 1.4 and then focus on 2.0.

Oh yea, the 2.0 Style system design. It sounds like you are putting
the Style system into an excellent test environment. In writing the 2.0
requirements documentation, your experience exemplifies the limitations of
our Style system. If Midgard 1.4 is a publishing tool, then it's heart is
the Style system. No?

Requiremnts Document for Proposed Solution: StyleGard

The problem is a need to manage style-elements (navigation bars, tables,
etc) by editing them and gracefully updating the existing style-element in
a way that makes use of the "infered" advantage of many elements that
can be inherited to build one element. Many elements, on a large project,
allows many developers to simultaneously work on the same job. The
solution must allow Style developers to use the tool of their choice;
DreamWeaver, FrontPage etc. No?

Solution, part1; an Admin Site, PHP, interface to manage a MySQL dump that
encapsolates the relevant style-element within an html template
(<html><body><[style-element]></body></html>) allowing it to be opened in
an independent editor? (Graceful because you can use any editor you want)

Problem; if the style-element is contstructed on the fly using CSS
to format, then the element to be edited doesn't have any formating tags
in it. To produce a stye-element that is comprehensive for DreamWeaver,
will pollute the style-element with formating tags that must be cleaned
out prior to the update.

The dump is written to the file system and transported to client localhost
via anonymous ftp. (not graceful)

Solution, part2; the edited style-element must be written back to the
database.

Localhost, client, uses ftp to upload the edited style-element, replacing
the original dump on the server. (efffective, not graceful)

Updating the database; style-element must be cleaned of formating
tags before the edited dump is written back into the database using
Midgard's authentication and SiteGroup ids. Is that the xml guid problem
we see discussed in reguards to Repligard?.

Problem; HTML could be cleaned with a Perl script but one
webmasters dirt is another's gold.

Solution, option for clean all formating tags or clean none. (graceful)

If this scenario is useful then I imagine it could be incorporated into
the 1.4 administration site.

-------------end of requirments doc-------------

I doubt this is a properly constructed requirements doc but...


I'm not suggesting that this idea amounts to a hill of turds. I am simply 
demonstrating that if you want to do it, I'll help write the
requirements document. From a documentation writer's perspective, I don't
think any features should be coded or excepted into 1.4 or 2.0 without
documentation from the programmer. Then again, I'm certain to end up in
Hell when I die so what do I know. What I do know, is it's difficult for
me to document an adhoc software application that's been extended
beyound it's original intented use when I can't study the damned
thing. So, my dependance on developers is beyound reasonable.

Exposing my limited understanding of software engineering, at the risk of
humiliating myself, has reinforced my appreciation for the Open Source
development model. I feel like I'm beginning to leave my Open Source
free beer fever in favor of an education. While I'm not an emotional guy
and haven't shed a tear in years, I might actually break down and begin
uttering inarticulate sobbing sounds. Wait, this entire response looks
like little more than exactly that.

Talk about a mouth full.

Ron
 
> anyway - thats enought thoughts for today :)
> 
> regards
> alan


--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org

To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]

Reply via email to