isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Nišević <vnise...@gmail.com>
Subject Re: collection of similar types
Date Thu, 26 Nov 2015 16:10:08 GMT
Hi Dan, thank you for your support!

Comments inline. 

Vladimir


> Am 26.11.2015 um 16:11 schrieb Dan Haywood <dan@haywood-associates.co.uk>:
> 
> Hi Vladimir,
> 
> thanks for pulling together that test case (though perhaps next time, just
> create a repo with just the simpleapp, rather than all of Isis?!?)
> 
Ok, will do so in the future!


> Anyway... the issue is a programming error, but easily made.
> 
> In some of your actions you are accessing fields directly, instead you
> should ALWAYS use the getters.  This allows DataNucleus to perform its lazy
> loading of state.
> 
Oh yes, I understand now! Isis solves so many things by magic, I wasn't aware any more of
that fact.

> For example, in Step.java:
> 
>    @Programmatic
>    public boolean isFinishedOrInError() {
> //        return status.isFinished() || status.isInError();
>        return getStatus().isFinished() || getStatus().isInError();
>    }
> 
>    @Programmatic
>    public boolean isProcessing() {
> //        return this.status.isProcessing();
>        return this.getStatus().isProcessing();
>    }
> 
>    @Programmatic
>    public boolean isPlanned() {
> //        return this.status.isPlanned();
>        return this.getStatus().isPlanned();
>    }
> 
> in StepSubtype1.java:
> 
>    @Override protected List<String> checkForErrorsBeforeExecute() {
>        List<String> errors = new ArrayList<>();
> //        if (this.technology == null)
>        if (getTechnology() == null)
>            errors.add("No technology defined");
> //        if (this.dslamLocation == null)
>        if (getDslamLocation() == null)
>            errors.add("No DSLAM location defined");
>        return errors;
>    }
> 
> in StepSubtype2.java:
> 
>    @Override
>    protected List<String> checkForErrorsBeforeExecute() {
>        List<String> errors = new ArrayList<>();
> //        if (this.dslam == null)
>        if (getDslam() == null)
>            errors.add("No dslam defined");
> //        if (this.port == null)
>        if (getPort() == null)
>            errors.add("No port defined");
>        return errors;
>    }
> 
> 
> 
> I suspect you've "got away with this" previously if you weren't using
> inheritance with each subtype in its own table.  But for this example, they
> do, eg:
> 
> @javax.jdo.annotations.Inheritance(strategy =
> InheritanceStrategy.NEW_TABLE)        /// this...
> public class StepSubtype1 extends Step {
> 
> 
> Either way, always use getters.  Moving actions into mixins (my new
> favorite feature of Isis) might be a way to help enforce this.
> 
> Cheers
> Dan
> 
> 
> 
>> On 24 November 2015 at 15:11, Vladimir Nišević <vnisevic@gmail.com> wrote:
>> 
>> Hi Dan, yes, that's exactly the problem.
>> 
>> I have adapted the simple-app trying to show my problem:
>> https://github.com/niv0/isis
>> 
>> Meanwhile I understood that my integration test was wrong - I haven't used
>> the wrapper. Now is my problem at least consistent through WebUI and
>> Integration test, but I still have it.
>> 
>> To reproduce:
>> 
>>   1. Start SampleAPP Webapp
>>   2. Create new simple object
>>   3. Execute action "Plan" on simple object (will add three steps of
>>   specific subtype). Two steps will have a specifc properties.
>>   4. Exectute action "Execute" on simple object - status of first step
>>   change to processing, but since properties are not loaded, business
>> logic
>>   prevent it from doing (my problem)
>> 
>> 
>> 
>> 
>> Regs,Vladimir
>> 
>> 
>> 2015-11-23 16:30 GMT+01:00 Dan Haywood <dan@haywood-associates.co.uk>:
>> 
>>> If I understand you correctly, sounds as if the query that you are using
>> is
>>> only querying the supertype table, rather than doing left outer jobs for
>>> all subtypes.
>>> 
>>> But in guessing here... perhaps you could share some code that
>> demonstrates
>>> the issue?
>>>> On 23 Nov 2015 3:20 pm, "Vladimir Nišević" <vnisevic@gmail.com> wrote:
>>>> 
>>>> Hi Dan, when I execute the action on order the steps instances are
>> there,
>>>> but the values of its properites are definitely empty - I've checked it
>>>> thru debugging of webapp. When I open a view of single step, the values
>>> of
>>>> that step are there.
>>>> 
>>>> I do not need to show additional values in a table, but have a problem
>>> with
>>>> business logic when executing an action which uses a data on single
>> step.
>>>> 
>>>> Any idea?
>>>> Thanks, Vladimir
>>>> 
>>>> 
>>>> 2015-11-23 14:25 GMT+01:00 Dan Haywood <dan@haywood-associates.co.uk>:
>>>> 
>>>>> The objects are loaded, however the Wicket UI uses the compile time
>>> type
>>>> of
>>>>> the list to determine what columns to render.
>>>>> 
>>>>> I could imagine us allowing some sort of hint for the framework to be
>>>> told
>>>>> to render the objects as per some other type (eg some "union
>> interface"
>>>>> that combines all desired properties). But that would be a new
>>> feature, I
>>>>> think.
>>>>> 
>>>>> Dan.
>>>>> On 23 Nov 2015 1:16 pm, "Vladimir Nišević" <vnisevic@gmail.com>
>> wrote:
>>>>> 
>>>>>> Hi, I have perhaps similar issue.
>>>>>> 
>>>>>> I have an object (Order) which contains a list of objects can be
>>>>> different
>>>>>> type but all extend from the same superclass (Step). When I execute
>>> the
>>>>>> action on order thru wicket UI, the properties of concrete classes
>>>>>> StepType1 and StepType2 are not loaded. When I do the same thru
>>>>>> Intergration Test, the values are there?
>>>>>> 
>>>>>> 
>>>>>> *class Order{*
>>>>>> *.....*
>>>>>> *//region > steps (collection)*
>>>>>> *@Column(allowsNull = "true")*
>>>>>> *@Persistent(mappedBy = "order", defaultFetchGroup = "true")*
>>>>>> *private List<Step> steps = new ArrayList<>();*
>>>>>> 
>>>>>> *@Collection(editing = Editing.DISABLED)*
>>>>>> *@CollectionLayout(render = RenderType.EAGERLY)*
>>>>>> *public List<Step> getSteps() {*
>>>>>> *    return steps;*
>>>>>> *}*
>>>>>> 
>>>>>> *public void setSteps(final List<Step> steps) {*
>>>>>> *    this.steps = steps;*
>>>>>> *}*
>>>>>> *....*
>>>>>> *}*
>>>>>> 
>>>>>> 
>>>>>> *abstract class Step{*
>>>>>> *....*
>>>>>> *//region > order (property)*
>>>>>> *@Persistent(defaultFetchGroup = "true")*
>>>>>> *@Column(allowsNull = "false")*
>>>>>> *private Order order;*
>>>>>> 
>>>>>> *@MemberOrder(name = "General", sequence = "1.1")*
>>>>>> *@PropertyLayout(named = "Order", hidden = Where.PARENTED_TABLES)*
>>>>>> *public Order getOrder() {*
>>>>>> *    return order;*
>>>>>> *}*
>>>>>> 
>>>>>> *public void setOrder(final Order order) {*
>>>>>> *    this.order = order;*
>>>>>> *}*
>>>>>> *.....*
>>>>>> *}*
>>>>>> 
>>>>>> 
>>>>>> *class StepType1 extends Step{*
>>>>>> *//region > ipAdresse (property)*
>>>>>> *private String ipAdresse;*
>>>>>> 
>>>>>> *@MemberOrder(sequence = "1")*
>>>>>> *@javax.jdo.annotations.Column(allowsNull = "true")*
>>>>>> *public String getIpAdresse() {*
>>>>>> *    return ipAdresse;*
>>>>>> *}*
>>>>>> 
>>>>>> *public void setIpAdresse(final String ipAdresse) {*
>>>>>> *    this.ipAdresse = ipAdresse;*
>>>>>> *}*
>>>>>> *....*
>>>>>> *} *
>>>>>> 
>>>>>> *class StepType2 extends Step{*
>>>>>> *....*
>>>>>> *private String dslam;*
>>>>>> 
>>>>>> *@MemberOrder(name = "Output", sequence = "1.0")*
>>>>>> *@PropertyLayout(named = "DSLAM")*
>>>>>> *@javax.jdo.annotations.Column(allowsNull = "true")*
>>>>>> *public String getDslam() {*
>>>>>> *    return dslam;*
>>>>>> *}*
>>>>>> 
>>>>>> *public void setDslam(final String dslamId) {*
>>>>>> *    this.dslam = dslamId;*
>>>>>> *}*
>>>>>> *.....*
>>>>>> *} *
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2015-11-22 15:23 GMT+01:00 Dan Haywood <
>> dan@haywood-associates.co.uk
>>>> :
>>>>>> 
>>>>>>> On 21 November 2015 at 22:01, Stephen Cameron <
>>>>>> steve.cameron.62@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Actually, it already does have the behaviour that I wanted.
>>>>>>> OK, that's good to hear.
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> I'll try individual icons for the subtypes and see if it
uses
>>> them
>>>>>>> instead
>>>>>>>> of the one for the base-type.
>>>>>>>> 
>>>>>>>> It should do.  In the todoapp we use the similar cssClass()
to
>>>>> return a
>>>>>>> CSS class name per instance, and then use application.css to
>> style
>>>> the
>>>>>>> different values.  This is how individual rows within a table
>> show
>>>> some
>>>>>>> todo items "crossed-off", ie with a line through the centre.
>> The
>>>>> icons
>>>>>>> also vary on a case by case basis.
>>>>>>> 
>>>>>>> Cheers
>>>>>>> Dan
>> 

Mime
View raw message