On 9/9/10 10:39 AM, Nate Lowrie wrote:
> On Thu, Sep 9, 2010 at 13:13, Paul McNett<[email protected]> wrote:
>> Yes. Tell me specifically what variables you are wanting to set and I'll
>> tell you the
>> best way.
>>
>> Report expressions can access the application object like:
>>
>> <expr>self.Application.<myfunc>()</expr>
>>
>> If you instantiate the report writer at runtime and assign an attribute,
>> like:
>>
>> def test(arg1):
>> return "Hi, %s" % arg1
>>
>> rw = dabo.dReportWriter()
>> rw.myMeth = test
>>
>> You can then refer to that in an expression like:
>>
>> <expr>"Value of dynamic function: '%s'" %
>> self.myMeth(self.RecordNumber)</expr>
>>
>> If you want subtotals of line items, you should definitely use Report
>> Variables,
>> which is what they are designed for.
>
> Specifically what I am looking for is a way to easily set certain
> values for items based on preferences. So, let's take your invoice
> for example. Say that my program allows you to define you logo,
> company name, address, and contact info as preferences stored in
> either the preference manager or the database. I want to be able to
> use them in the report.
>
> I see that in this case it would be easiest to define the preferences
> in the preference manager and use the app object reference in the
> string expressions to pull those in that way.
However you define these, it seems like an application-layer thing to me since
you
may want to access this information from potentially a bizobj, a UI form, or a
report. I put them as properties of my dApp subclass, or optionally using the
setAppInfo()/getAppInfo() built-in machinery.
So from the report it is easy:
<expr>self.Application.getAppInfo("CompanyName")</expr>
> The other example where this might be useful is with the order itself.
> The case where you have a single row (order) parent joined with
> children in a de-normalized set can largely go away if you define the
> single row parent (order) as attributes in a dictionary referenced by
> the application object. It saves you from having to de-normalize the
> sets and an is largely quicker.
I don't understand this part. Why are you referencing the app object here?
What's the
problem with denormalizing the data?
> The problem I foresee in this approach is not being able to properly
> preview the report... What do you think about adding in a
> TestVariables section to allow you to define static values for
> variables?
So when you are testing you see the test values instead of running the
expressions? I
guess it wouldn't hurt...
> Also, how would you programatically run a report and is this a report
> list/run dialog already built into dabo?
To see how to programatically run a report, see the invoice sample, invoice.py.
No, there is nothing built into dabo for previewing/printing reports however
there
are supporting functions in dabo.lib.reportUtils.
I've made my own FrmReport that I subclass for each report.
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
