>
> > Personally I'm using:
> > * yahoo grids for layout (CSS library)
>
> I haven't actual experience with any of the CSS grid layout systems --
> anything you can comment on how it is working out?
>
Yahoo grids is great. I download and copy and paste their base CSS file at
the beginning of my wt.css. I use the 'full one':
http://yui.yahooapis.com/2.9.0/build/reset-fonts-grids/reset-fonts-grids.css
Then I use the cheat sheet to apply classes to my witty widgets and
containers: http://yuiblog.com/assets/pdf/cheatsheets/css.pdf
For the main page layout on a new project I use the online builder, then
copy and paste that into a WTemplate widget:
http://developer.yahoo.com/yui/grids/builder/
It is very convenient and works well cross browser.
I have had one time where widgets tried to float down to the next row, due
to thick borders and margins on the internal witty widgets, but is easily
compensated for.
> Actually ... I already have a local git branch "dbo-mongo". The idea
> is to abstract away the Sql in Dbo so that it could also be used for a
> document store (or other types of database).
>
Push it up to the public repo :) I'll see if I can use / contribute maybe.
I'm using the mongo::Model class .. but I find it annoying that I have to
declare the field names and references twice (serialize and unserialize).
I've been investigating maybe using some of the boost::tuple or fusion
stuff, so I can declare a single compile time map<char*, tuple<sometype&> >
in one place ie. "fieldName": value& - and derive automatic serialize and
unserialize methods from that.
MongoDB's features map quite well on Dbo API, but of course the query
> language (in session.query() and session.find() will be different),
> and some things do not apply to MongoDB, and probably some things from
> MongoDB would not apply to Sql.
>
> The mapping I had in mind would be to define a "root" class (or
> perhaps more than one?) which corresponds to documents, and in which
> related objects are stored (in JSON syntax).
>
could you explain a little more on that ?
I'm using basically a "object = document" map. And I do have relations in
there storing a straight mongo::OID, for example:
mongo::OID parentId;
ParentType getParent() {
ParentType result;
.. mongo query stuff for parentId ..
return result;
}
I considered using factories and object caches and stuff, but I'm thinking
mongo should be fast enough, so I just create objects left right and center
and have no synchronization between existing objects that might represent
the same doc in the DB, so last one to write changes wins basically.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
