I've had a couple of ideas on some of this (kinda off AND on topic)
I'd really like to see a 'webware parts' type setup ,perhaps as a plugin,
where theres a central repository of pre written objects that page
designer could drop into his/her own design to achieve various
functionalities that'd otherwise have to take a rewrite.
If you could imagine;- Theres a central repository anyone can drop objects
into. A 'testing' so to speak. Folks can then check em out and see if they
are kosher, or require a little fixing, or even scrapping. Then they are
moved into a 'tested' repository. An interface in the webware admin, can
retrieve this, and say "Hey I'd like a little email client to stick in
this intranet thing I'm doing". Click a button, and it downloads and puts
it into a directory somewhere. CPAN style really.
If theres essentially a style guide, with an apropriatley *simple*
template, auth, and rendering structure behind it, someone could then
drop into the servlet;-
mailclient = webwareparts.mailclient()
.. or something like that.
As webware grows, these components will become more common, and eventually
big projects will reduce down to the same sort of simplicity RAD environs
like delphi and boa-constructor provide.
Something to mull over. I *could* write the code for that (later, big
project to finish first), though you may notice I'm not using the full
webware kit yet. Still learning.
An rdf capacity would be handy (hidden agenda: I need an rdf class) and a
forum would be nice.
I wonder what the logistics of porting squishdot from zope is? Thats a
plenty fine little news/forum system.
I know how hard it is for you to put food on your family."
----George W. Bush
On Sat, 10 Apr 2004, Ian Bicking wrote:
> On Apr 10, 2004, at 3:51 AM, Eric Radman wrote:
> > On 16:16 Fri 09 Apr , Ian Bicking wrote:
> >> And if we're going to host this on Webware, should we be doing
> >> something
> >> fun and dynamic? I can't think of anything for the front page that
> >> would make any sense, though.
> > Perhaps we could build a home page that is essentially a moderated
> > Wiki portal.
> > This would turn webwareforpython.org home page into interactive
> > news/idea/documentation/source code site. The archive of Wiki updates
> > could
> > then be pruned and rolled into current documentation.
> > In my mind this Wiki-home-portal site would blend features of:
> > - User contributed documentation (http://www.php.net/manual/en/)
> This tends to be annotation-style, which may be somewhat different.
> Though ZWiki has an idea of commenting on a page vs. editing it -- but
> in reality it's just append vs. edit, and someone with editing
> permissions can rearrange the whole thing as they see fit.
> > - Searchable Forums (http://forums.gentoo.org/)
> Is a good full text search sufficient?
> > - User-based information and access (http://my.yahoo.com/)
> I think this is too optimistic -- we're not daily destination, after
> all. The exception would be RSS feeds, which I very much like.
> > - Repository for reusable components (http://cpan.org/)
> In an ad hoc way this could be the Wiki, especially if we allow
> attachments or binary pages.
> > If this were to work properly a small group of wiki managers would
> > take turns
> > reviewing and cutting, and committing new Wiki posts. We don't need
> > useless
> > material!
> I'm not that worried about bad material. Out-of-date material,
> certainly, but that's kind of a separate issue -- well, it takes some
> editorial work on people to keep the house clean.
> > The paradigm shift that I'm talking about is transitioning from the
> > idea of
> > "home page" to "portal".
> > Are you tracking with this idea or am I in orbit?
> I'm certainly interested in all this. I've been working quite a bit on
> a Wiki in the last couple days (in the w4py repository), and I feel
> optimistic about using it fairly expansively. ReST is a real markup
> language, and I think is high enough quality to be the canonical format
> for documentation -- something that a lot of other Wiki markups don't
> achieve. It's not good at complex layout, but it's good for content,
> so I think most content pages could be adapted into reST form, and
> non-Wiki pages are allowed for.
> I'm also putting it in place so that one domain can use the same
> content as another domain, but with different controls. So
> webwareforpython.org could appear static, but wiki.webwareforpython.org
> could allow editing, which would be immediately reflected on the other
> site. Even more granular control would be possible.
> With some more metadata, we could probably do whatever we wanted.
> E.g., we'd want to mark documentation differently from user pages or
> brainstorm pages -- but instead of creating separate hierarchies, we
> can simply annotate pages to reflect their role(s) in the system.
> Right now I've just started converting our current Wiki pages over to
> reST, which is kind of tedious, but once it's done I'll be able to
> better see how it works for a real site. Once I've done that I'll set
> it up on the w4py server; hopefully this weekend.
> Ian Bicking | ianb@... | http://blog.ianbicking.org
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> Webware-discuss mailing list