raja_s_patil wrote:

> Thanks Lester Caine,
>
> I was expecting your response ;)-
>
> well as per plan as of today we are porting a database application
> to web. What flex application will access from web server are
> various web services which are going to access database either
> on same server or altogether different server that's all.
> It's not expected or planned to provide facilities like
> blog, html pages etc. etc.
>
> Well while drafting specs both we and our client dont have any
> past experience of having a web application so it might be
> a wrong plan. So i will give a profile of present application
> so that u can guide us better.
>
> The application is for a small courier company. They have
> branches at various location and at those branches our application
> is running. They want to have a centralized database and a parcel
> tracking. At present we are using data replication and collecting
> data from individual branches. The only thing they need is
> web interface for their customers who will be able browse the
> status of their parcel right now. However for future requirement
> we have considered that capability of data capturing through
> browser should exist in platform we are going to select. We
> are aware that once parcel tracking system is put on line
> it is very difficult to change the platform. So we want to
> do it right since begining.
>
> What do u thing is it necessary to have a server side framework
> essential for such type of applications ? We are in the
> line of custom database applications.

I would suggest that a single central database that the customers check
is probably the correct approach. ADOdb can access multiple databases,
and so later developments could update the central copy with local more
accurate data as required, so sections of your bespoke system could be
replaced by additional pages on the web based system over time?

bitweaver would provide login, front page, calendar of events, faq
section and so on - out of the box, and any branch could update and
extend the content that displays using the on-line editor.

An additional package would then create 'content' which are packages to
be tracked, and would have a secondary table with actions against a
parcel. My 'tasks' package has 'tickets' for each enquiry, and then
'transactions' such as serving, waiting on queue, interview and finished
- these would translate to your collected, in transit to, delivered ...
so the bulk of the work is probably available. Customers would only be
able to see their own packages, branches may either see all packages or
just their own ;) Making a package that can handle your existing tables
is easy - my own stuff is connecting to the same tables as are used by
MY legacy windows applications!

I have my own map package for bw which uses scanned maps, but Will has a
very nice interface to google maps - which I've not actually used myself
- but I understand you can do things like showing the closest branch, or
display a location from the database - which could be GPS direct from
the delivery van ;)

Extending the package to allow booking parcel collections would be easy,
the bitcommerce package provides a range of payment options. That would
be a little more work as the bitcommerce shop is not as integrated as
some other packages, but the structure is all in place and is handling
some large sites already.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php