> > I have already explained that OffstageArts is a two-tier application > > with the client launched off the web via Java Web Start (no server-side > > Java required). And the server is a plain jane PostgreSQL database. > > Hosting for OA (or any other system with similar architecture) will be > > provided over the Internet by running a server with: > > a) A PostgreSQL server > > b) An SSL tunnel adapter, used to conect to the server. It both > > encrypts communication and prevents random people from hitting the > > PostgreSQL port. This adapter can be SSH, if you like. (This scheme is > > probably more secure to remote vulnerabilities than a PostgreSQL > > database with phpPgAdmin in front of it). > > > > Because this kind of hosting is much simpler than LAMP hosting (and > > doesn't require the host to know or care which version of OA is being > > run), it will actually be very cheap to provide. I'm aiming for an > > on-line service to be able to offer it for $10/mo per database. In this > > way, NPOs won't have to install anything, not even on their cheap LAMP > > hosting. > > Very interesting architecture. I like your outside of the box thinking. >
I briefly described how customization works in OA here: http://lists.flossfoundations.org/pipermail/foundations-software/Week-of-Mon-20081020/000037.html and a bit more of a writeup here: http://lists.flossfoundations.org/pipermail/foundations-software/Week-of-Mon-20081020/000038.html actually here (in more detail): http://offstagearts.org/?q=docs These docs are still in alpha. The programmer docs will soon have fully worked-out examples with code. Here are some examples (screnshots) of different OA customizations in practice: http://offstagearts.org/tmp/devel1.tiff http://offstagearts.org/tmp/devel2.tiff > Don't you think it makes it harder to customize for "normal" users ? My "normal" users can't do much more than click a mouse. I've assumed each NPO will have a consultant supporting its use of OA. I've then worked to make life easy for that consultant (and therefore cheap for the NPO) by reducing time needed to service the system, and by eliminating the need to be on-site. The above manuals are the start of the consultant docs. It will describe step by step how a consultant can cutomize OA in common ways. This is a skill the consultant has to learn, of course, but I've made it as easy as possible. > One of the benefit of the Civi approach (or any script language on the > sever) is that you can easily copy a template file and put it into > your custom folder, and tweak it the way you want (that's html with a > bit of template language, that mostly everyone can adapt). > When you update, you just have to copy your custom templates on the > updated install and that's done, that's reasonably easy to do. I've found that to be less than ideal (some of which can be solved with good docs, of course): 1. There's no support to keep track of which templates are copies that you need to keep track of, and which are not. 2. There's no guarantee that a page you modify won't break with an upgrade. 3. There's no way to test that the upgrade doesn't break your customizations without testing it. OA screens are customized by subclassing and overriding GUI panel layouts (and other classes). Classes must be designated in the core code as customizable before they can be overridden (i.e. you can't override undocumented stuff that will break later). And if an upgrade DOES break your code, you might find out if you try to compile your customizations against the core codebase. > I understand that you can probably do the same with OA, but I suppose > it needs to change the java (or templating) code, recompiling, Customizations are loaded into the database as a JAR (.so with symbols) file. You create a small customer-specific project and compile it against the main OA JAR file. So everyone can share the same core code binary (off the offstagearts.org website) while enjoying their own diverse customizations. The app is linked together at runtime by linking the core code with the custom code. > and > keep your changes under a code versionning system to sync with the > evolution of the core, right ? You do have to sync your customization project with the evolution of the core, but only when the core's exposed API changes. That's no different from the web approach described above. > Another "native" feature of a web app is that it's very easy to send > links to a specific donation, contact, issue. You just copy the url > and email it to your teammate (that sounds stupid, but that's probably > the most used feature). > do you have something similar with java ? Frankly, I never thought of this. The OA app is organized as a set of windows, each window with a set of tabs. It would not be hard to assign each window/tab combo a pathname (they already have names, so building pathnames would be easy) and then making a "jump to" feature that would make the correct window/tab combo display. > I think the goal for an NGO is to increase the number of > customer-facing feature (eg "donate now" widget, or register to this > event, or register to the mailing list XYZ, or pay your membership, or > self-customer care so they can update their contact details, or add a > new contact, or display on their web the list of the members, of the > sponsors, of the volunteers ...) Yes! > For an NGO that wants to be transparent, that wants to engage their > members and contacts and increase the interaction with them, the > number of these features that needs to be web aware is likely to grow, > with a bigger and bigger overlap with the back office features. The overlap happens in the database. It's no different from so many web apps out there with customer screens and administrative screens. > > > There are many ways to integrate this kind of stuff with a website. > > Absolutely, but having a different core technology means that the web > components are an extra development. It's not really a different core tech. They share a DB. And if I decide to run a Java-based web framework, then I can share code between the front-end and the web back-end as well. Java and .NET are probably the only technologies I know of that can work equally well for GUI apps and web servers. Moreover, OA's core technology is the Holyoke Framework --- a system that automates both query generation and GUI population based on the database schema types. Query generation has been automated by many (eg) object-relational mappings. But GUI population really has not, this is new. Holyoke greatly increases the speed at which one can build (and modify) full-functional, fully interactive, fully typechecked GUI screens. I'd love for there to be an easy way to use the same framework to populate web GUIs just as easily as Swing GUIs. But if I don't figure it out, I know that there are plenty of tried-and-true web technologies out there that will work fine as well. > IMO a risk of being left behind > and not as well feature rich, nor updated and tested. This risk exists no matter what tech the screens are built in. And it's one I've experienced. -- Bob _______________________________________________ software mailing list [EMAIL PROTECTED] http://lists.flossfoundations.org/mailman/listinfo/foundations-software
