Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Collapse
Posted by bill kellerman on
i was initially attracted to the acs through greenspun, the book, and the charisma of arsdigita.  i worked in a crappy, stereotypical dot-com that did everything wrong, and what appeared to be a clearly-defined vision of "do the most with the least and keep your perspective" was exciting.

i still get excited by the possibilities of the openacs, and there are a lot of damn smart people involved.  is there a groove?  do things flow easily?  not for me.  i agree it's partly due to circumstance, partly different visions and ideas.

as a new user to oacs, there are a million ways to do things and no way to tell which one is correct or to know if it will change as soon as you take the time to learn it.  i'm new to oacs but not web development -- the complication is learning another person's idea of the way things should be done.

one of my perpetual roadblocks is wondering why things are done the way they are and why they seem so complicated.  i obviously understand the necessity of certain complexities...  oacs installation and management is better than ever, the permissions system is wonderful.  however, some of the modularity and abstraction and objectification and all brings back bad memories of old employers and clients justifying futile efforts to rewrite sites in java.  yes, it is my responsibility to figure out what is going on -- but that is my point.  it can be difficult to do that.

i think the original acs was easier to absorb because development seemed to lean more towards providing acceptably-balanced standards and tools to solve human problems.  maybe the oacs concentrates more on providing the perfect solution to technical problems.  i don't know if considering whether developers should know sql or learn another database abstraction methodology is the right focus.

as far as my experience with the code or direction, my big bastard enemy is xml.  i understand the theory, i've found cool things to do with it, but i have yet to understand why it's worth the complexity.

i like the idea of bringing back bootcamps in some form.  why not deliver them through dotlrn?  use the tools being developed to teach the community.  what if the people voted on to the board of directors were encouraged (or required) to teach or contribute to a bootcamp?  ...just throwing some ideas around.

Collapse
Posted by Tilmann Singer on
Regarding xql files I meant to say that I don't use them in the beginning when prototyping a package or when I'm working on a specific package for a client that will always use one db only and is not intended to be redistributed, that's all. The ability to write inline queries makes developing a little quicker but of course for general packages xql files should be used. Btw, making inline queries explicit with an -sql switch sounds great and would eliminate lots of confusion for newcomers too.

Ola, forum::get has the other drawback of being slightly inefficient by selecting more fields than needed, propably it doesn't matter in this case at all, but it's symptomatic for the dangers of redirection via tcl apis for queries. I would prefer using something like "set forum_name [db_string get_forum_name {}]" instead, possibly with a reused xql file if that query is used more often.