Ah, wonderful stuff!
I had made my own form class for PHP3 and I still use it to this day, when I am
relegated to PHP.
________________________________
From: Matthew Sherborne <[email protected]>
To: Jason H <[email protected]>; [email protected]
Sent: Wednesday, July 11, 2012 11:24 AM
Subject: Re: [Wt-interest] Code generation script - RFC
Hi Jason,
Thanks for the comments.
I definitely don't want to add scripting to Wt.
What I have in mind is just a command line script that generates C++ code,
cmakefiles, starter css, wt-config.xml, and possibly some images that end up in
all my Wt projects in the end anyway.
I did have a couple of cracks at libraries on top of C++:
* My first one died because it turned out that Wt devs were working on the
same thing I was (Auth), and they did it a lot better:
https://github.com/matiu2/witty-plus
* My second one, which I will continue to work on I think:
https://github.com/matiu2/wp2
So the reasons I want to do the code-gen more than the libraries is:
* The resulting code from the code gen has less learning curve. (You only need
to know Wt)
* It may help people new to Wt understand how it works at the same time as
getting things done.
* It may help promote some 'best practices' when devving with Wt
* The result has less dependencies, like once you've run the script, you don't
need to install an extra library
Regarding your 'Form Class' comment; my old lib adds a 'form' class:
https://github.com/matiu2/witty-plus/blob/master/wittyPlus/base/MoreAwesomeTemplate.hpp
It uses Wt templates and CSS for layout and depends on all the other bits in
the library, but it gives you the easiness of adding a label+widget in one line.
But nowadays, I prefer to use the WLayout WBox for label+widget pairs, and so
that's available in the new library, with practically no dependencies:
https://github.com/matiu2/wp2/blob/7d42bd256c8041ae3e94d2fb9b8b9ad39c1d957e/wp2/LabelWidgetPair.hpp
That really does belong in a library I think rather than in code gen script,
but I'm considering making part of the code that the script generates be some
really simple lib funcs like that, then you can choose to use them or not, and
the code is right there in your project, easy to access and understand.
Wt itself has a kind of form class in it now, and I suspect they might add more
to that in the future, so I don't want to duplicate their work again:
http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WFormModel.html#details
Yeah, mixing Wt and python sounds like a bad idea to me too :)
If more and more does want to be done by the script, that'd be cool; we'll see
how it goes.
I'm also considering doing the 'script' in C++ too rather than python; I hope
to make it into qtcreator plugin at some point too. And I have in mind, to
maybe make a Wt app itself, with a nice gui that generates the starter code for
your project and lets you download it as a zip file.
Kind Regards,
Matthew Sherborne
On Thu, Jul 12, 2012 at 12:52 AM, Jason H <[email protected]> wrote:
I am not sure I completely understand the concept. It seems to me that you want
to add a scripting language to Wt to make development easier, kind of like how
fast it is to get a site going developing in PHP, something to get you up and
running faster? My thinking is if it gets your running faster, why can't you
keep running with it? Which then got my mind thinking about merging Wt with
Python. But that has things like GILs, etc. For me the strength of Wt is that
it is not interpreted. Then I got to thinking that your OOP language/library
should just do it for you. So why can't there be some "site" class and a form
class.
>
>
>
>Forgive me, I'm not that experienced with Wt, but it seems that if you are
>going to champion OOP of websites, that a fall-back to as scripting language
>is a cop-out. And while the issue is currently about generating a template and
>coding OOP from there, I fear/predict more and more will want to be done with
>the script. So I put the challenge out there... can we jsut add a few classes,
>intellifently derive from them and accomplish the same thing?
>
>
>
>
>
>
>________________________________
> From: Matthew Sherborne <[email protected]>
>To: [email protected]
>Sent: Wednesday, July 11, 2012 10:29 AM
>
>Subject: Re: [Wt-interest] Code generation script - RFC
>
>
>
>Hi Nagaev,
>
>Thanks for the ideas.
>
>I've made an initial plan:
>https://github.com/matiu2/witty-codegen/blob/master/README.md
>
>Please have a skim read and see if anything pops out. All comments would be
>most appreciated. Let me know if I've overlooked some great big thing, or if
>my ideas seem crazy, or if you can think of better ways of doing things.
>
>Many Thanks,
>Matthew Sherborne
>
>
>
>
>On Tue, Jul 10, 2012 at 7:52 PM, Nagaev Boris <[email protected]> wrote:
>
>Hello!
>>
>>It would be a great script! If the project will begin, I want to take part.
>>
>>IMHO, this script should produce minimal code, which would probably
>>taken mostly from Wt examples (e.g., pieces of Auth can be taken from
>>Hangman example). The code generated should be at the same time
>>flexible enough to make it easy to modify or extend it.
>>
>>I want this script also had these features:
>> * add model (asks model name, adds empty model, mapping
>>(Session.map<Model>()), maybe also typedef for dbo::ptr and
>>dbo::collection)
>> * add widget (asks ancestor widget and new widget name, adds empty
>>widget, inherited from that ancestor)
>> * commands to work with XML translations: add language, add new
>>message. I have written script locales-test (
>>http://pypi.python.org/pypi/locales-test/1.4.0 ), checking Wt
>>translation files, for example, that all translation IDs, passed to
>>WString::tr(), are present in .xml files. It can be also used.
>>
>>There is also a problem of Wt version used. I believe that newer
>>versions are better than older ones, however versions restrictions can
>>be applied. For example, project requirement can be to use packages
>>only from Debian stable (i.e., Wt 3.1.2). So, the script should accept
>>Wt version (or version range) as an argument. This causes restrictions
>>on other commands of the script. For example, Wt < 3.2.0 had no Auth.
>>
>>
>>On Tue, Jul 10, 2012 at 11:32 AM, Matthew Sherborne
>><[email protected]> wrote:
>>> Hi guys,
>>>
>>> I want to ask if there's any interest from the community in working together
>>> on some kind of project code generation automation.
>>>
>>> Witty itself seems to be going the direction of adding higher and higher
>>> level libraries, but keeping mega flexibility. For example the auth module,
>>> you have to plug together a bunch of pieces to get password auth going.
>>>
>>> What about either a library on top that says, just give me password auth.
>>> Then just give me a form with basic controls for these DB fields.
>>>
>>> But better than a library, what about a command line code generation script,
>>> similar to django-manage, but less magic.
>>>
>>> The code generation would be better than a library in that you could
>>> customize the code after you generated it.
>>>
>>> It'd be better than django-manage as it'd generate explicit code and not a
>>> bunch of airy-fairy magic giving us no idea how it works.
>>>
>>> Here's my initial thoughts to kick off the conversation; it'd be nice if we
>>> could get together a good list of features and a bit of a spec.
>>>
>>> Here's my initial feature wish list:
>>>
>>> * Gen app - asks for the app name and stuff, generates you a main.cpp, a
>>> MainWindow.?pp CMakeLists.txt, and builds and runs it for you, so you can
>>> get into witty quickly.
>>> * Gen tests - Creates a tests dir, CMakeLists file (with a nice 'addTest'
>>> function that you can use), and an initial test using boost test framework
>>> * Gen Password Auth - Generates an Auth.?pp that just does password auth
>>> * Gen DB - Generates a db directory, CMakeLists.txt, and a User model, and
>>> source code for a DB reset/repopulate util app
>>> * reset DB - runs the app from the line above
>>> * Gen Form - Parses a model source file, and generates a form for it, just
>>> choosing the simplest widgets it can.
>>>
>>> You could possibly have different backends, that generate the code in
>>> different ways; for example one that uses CSS for layout, one that uses
>>> WLayout controls and so on. Or different styles, but if we could standardize
>>> the feature list and possibly some sort of calling convention between the
>>> layers, this could all happen.
>>>
>>> That's it for starters for me, it'd be very useful in reducing the learning
>>> curve getting into Wt, and encouraging noobs to write pretty code, and for
>>> people that write a lot of apps in Wt, could reduce the time to market for
>>> each app.
>>>
>>> I'm sure a lot of us will already have some bits and pieces cobbled
>>> together. It might just take a little planning and a little sharing and we
>>> can do this.
>>>
>>> All comments and thoughts appreciated.
>>> Matthew Sherborne
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> witty-interest mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/witty-interest
>>>
>>
>>------------------------------------------------------------------------------
>>Live Security Virtual Conference
>>Exclusive live event will cover all the ways today's security and
>>threat landscape has changed and how IT managers can respond. Discussions
>>will include endpoint security, mobile security and the latest in malware
>>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>_______________________________________________
>>witty-interest mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/witty-interest
>>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>witty-interest mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>witty-interest mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
