Home » Modeling » EMF » [XCORE] Initializing a feature
| [XCORE] Initializing a feature [message #1278909] |
Fri, 28 March 2014 01:54  |
Eclipse User |
|
|
|
Couple of Xcore related questions and a comment...
I have an Xcore class and datatype:
abstract class Event {
Date date
String comments
}
type Date wraps Date
create {
try {
if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
} catch (ParseException parseException){
throw new RuntimeException(parseException)
}
}
convert {
if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
}
* How can I initialize the date feature in the child Event classes to
the current date when the event is first constructed?
* What is the best way to keep the src-gen code separated from the src
authored source code? Are there any examples?
* thanks for creating the very cool Xcore!
John
|
|
| |
| Re: [XCORE] Initializing a feature [message #1279683 is a reply to message #1278979] |
Sat, 29 March 2014 04:17  |
| Eclipse User |
|
|
|
Ed
See in line comments...
On 03/27/2014 11:34 PM, Ed Merks wrote:
> John,
>
> Comments below.
>
> On 28/03/2014 2:54 AM, John E. Conlon wrote:
>> Couple of Xcore related questions and a comment...
>>
>> I have an Xcore class and datatype:
>>
>> abstract class Event {
>> Date date
>> String comments
>> }
>>
>> type Date wraps Date
>> create {
>> try {
>> if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
>> } catch (ParseException parseException){
>> throw new RuntimeException(parseException)
>> }
>> }
>> convert {
>> if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
>> }
>>
>>
>> * How can I initialize the date feature in the child Event classes to
>> the current date when the event is first constructed?
> You can't and probably shouldn't. After all, such classes are also
> created during copying and deserialization, in which case such a date is
> typically overwritten later (and if not should not have been set,
> because it wasn't set in the original object)...
Your right. I used this hack before and got away with it, but I must
reform my ways...
This is a convenience for the user, they create a new event and it has
the current date.
So if not in the constructor, where is the best place for setting the
date to the current date on user creation? Would it be in the Packages'
FactoryImpl in the create methods or in the Event parents ItemProvider
in the x.x.x.edit.provider package?
>>
>> * What is the best way to keep the src-gen code separated from the src
>> authored source code?
> The Xcore builder automatically keeps all the generated Java source
> separate. Is this question about modifying that generated source?
Have seen previous threads showing how to move all the generated code to
the src folder, by annotating the package with:
@GenModel(modelDirectory="/<your-project-name>/src")
then one can follow @generated_NOT approach like before.
If one uses this technique which generates everything in the src folder,
does this effect the edit and editor bundles that are created when the
appropriate attributes are set to in the properties view? (Edit
Directory, Editor Director)
For example if I set the Edit Directory to /<your-project-edit-name>/src
Will the @generated_NOT approach work in my itemProviders to prevent the
code from being overwritten?
And conversely if I set the Edit Directory to
/<your-project-edit-name>/src-gen the code is always overwritten?
> Or about how to separate such modifications (for which there is no current
> mechanism, though I've been toying with the idea of reusing the approach
> used by the Xtext folks where the generator can detected that for
> generated implementation class XImpl there exists an XImplCustom that
> extends XImpl and then everywhere XImpl is referenced, XImplCustom is
> referenced instead...
What you suggest would be the best, but for the current release what is
the best practice to use both src and src-gen source directories to keep
gen code and custom code separate?
For example to initialize my date when it is first created by the parent
itemProvider?
>> Are there any examples?
>>
>> * thanks for creating the very cool Xcore!
> It would be nice to have more time to evolve the features of Xcore more
> quickly....
Ed - You have done so much already thanks.
|
|
|
| Re: [XCORE] Initializing a feature [message #1279686 is a reply to message #1279683] |
Sat, 29 March 2014 04:23 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
John,
Comments below...
On 28/03/2014 9:01 PM, John E. Conlon wrote:
> Ed
>
> See in line comments...
>
>
> On 03/27/2014 11:34 PM, Ed Merks wrote:
>> John,
>>
>> Comments below.
>>
>> On 28/03/2014 2:54 AM, John E. Conlon wrote:
>>> Couple of Xcore related questions and a comment...
>>>
>>> I have an Xcore class and datatype:
>>>
>>> abstract class Event {
>>> Date date
>>> String comments
>>> }
>>>
>>> type Date wraps Date
>>> create {
>>> try {
>>> if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
>>> } catch (ParseException parseException){
>>> throw new RuntimeException(parseException)
>>> }
>>> }
>>> convert {
>>> if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
>>> }
>>>
>>>
>>> * How can I initialize the date feature in the child Event classes to
>>> the current date when the event is first constructed?
>> You can't and probably shouldn't. After all, such classes are also
>> created during copying and deserialization, in which case such a date is
>> typically overwritten later (and if not should not have been set,
>> because it wasn't set in the original object)...
>
> Your right. I used this hack before and got away with it, but I must
> reform my ways...
>
> This is a convenience for the user, they create a new event and it has
> the current date.
> So if not in the constructor, where is the best place for setting the
> date to the current date on user creation?
If users are involved, it's generally something you'd do in the item
providers...
> Would it be in the Packages' FactoryImpl in the create methods or in
> the Event parents ItemProvider in the x.x.x.edit.provider package?
The latter, though it can be a significant amount of manual updating of
the child descriptors if the type of child can be created in many
different contexts...
>
>>>
>>> * What is the best way to keep the src-gen code separated from the src
>>> authored source code?
>> The Xcore builder automatically keeps all the generated Java source
>> separate. Is this question about modifying that generated source?
>
> Have seen previous threads showing how to move all the generated code
> to the src folder, by annotating the package with:
>
> @GenModel(modelDirectory="/<your-project-name>/src")
Yes. If you direct the source to a folder different from the project's
preferences for the "src-gen" folder (so configuring that preference to
something else also works), then things like a clean build will not
delete all your sources and you get merging as normal.
> then one can follow @generated_NOT approach like before.
Exactly.
>
> If one uses this technique which generates everything in the src
> folder, does this effect the edit and editor bundles that are created
> when the appropriate attributes are set to in the properties view?
> (Edit Directory, Editor Director)
Only the model project supports a "src-gen" folder (because you can't
specify any of the hand written logic you might write for item providers
or the editor via Xcore)...
>
> For example if I set the Edit Directory to /<your-project-edit-name>/src
> Will the @generated_NOT approach work in my itemProviders to prevent
> the code from being overwritten?
It will always work.
> And conversely if I set the Edit Directory to
> /<your-project-edit-name>/src-gen the code is always overwritten?
No, it will always merge (unless generated into the model project)...
>
>
>
>
> Or
>> about how to separate such modifications (for which there is no current
>> mechanism, though I've been toying with the idea of reusing the approach
>> used by the Xtext folks where the generator can detected that for
>> generated implementation class XImpl there exists an XImplCustom that
>> extends XImpl and then everywhere XImpl is referenced, XImplCustom is
>> referenced instead...
>
> What you suggest would be the best, but for the current release what
> is the best practice to use both src and src-gen source directories to
> keep gen code and custom code separate?
There isn't one.
> For example to initialize my date when it is first created by the
> parent itemProvider?
Only hand written mechanisms are possible.
>
>
>
>>> Are there any examples?
>>>
>>> * thanks for creating the very cool Xcore!
>> It would be nice to have more time to evolve the features of Xcore more
>> quickly....
>
> Ed - You have done so much already thanks.
Separation of generated and hand written source is kind of a religious
issue, so while I have my own perspective on that, supporting other
perspectives seems wise...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [XCORE] Initializing a feature [message #1279986 is a reply to message #1279686] |
Sat, 29 March 2014 15:50 |
| Eclipse User |
|
|
|
Ed,
Comments in line...
On 03/28/2014 11:23 PM, Ed Merks wrote:
> John,
>
> Comments below...
>
> On 28/03/2014 9:01 PM, John E. Conlon wrote:
>> Ed
>>
>> See in line comments...
>>
>>
>> On 03/27/2014 11:34 PM, Ed Merks wrote:
>>> John,
>>>
>>> Comments below.
>>>
>>> On 28/03/2014 2:54 AM, John E. Conlon wrote:
>>>> Couple of Xcore related questions and a comment...
>>>>
>>>> I have an Xcore class and datatype:
>>>>
>>>> abstract class Event {
>>>> Date date
>>>> String comments
>>>> }
>>>>
>>>> type Date wraps Date
>>>> create {
>>>> try {
>>>> if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
>>>> } catch (ParseException parseException){
>>>> throw new RuntimeException(parseException)
>>>> }
>>>> }
>>>> convert {
>>>> if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
>>>> }
>>>>
>>>>
>>>> * How can I initialize the date feature in the child Event classes to
>>>> the current date when the event is first constructed?
>>> You can't and probably shouldn't. After all, such classes are also
>>> created during copying and deserialization, in which case such a date is
>>> typically overwritten later (and if not should not have been set,
>>> because it wasn't set in the original object)...
>>
>> Your right. I used this hack before and got away with it, but I must
>> reform my ways...
>
>>
>> This is a convenience for the user, they create a new event and it has
>> the current date.
>> So if not in the constructor, where is the best place for setting the
>> date to the current date on user creation?
> If users are involved, it's generally something you'd do in the item
> providers...
>> Would it be in the Packages' FactoryImpl in the create methods or in
>> the Event parents ItemProvider in the x.x.x.edit.provider package?
> The latter, though it can be a significant amount of manual updating of
> the child descriptors if the type of child can be created in many
> different contexts...
Yep, just what I thought. Wanted to make sure that I wasn't missing
some subtlety or a 'cooler' way to do it;-)
>>>>
>>>> * What is the best way to keep the src-gen code separated from the src
>>>> authored source code?
>>> The Xcore builder automatically keeps all the generated Java source
>>> separate. Is this question about modifying that generated source?
>>
>> Have seen previous threads showing how to move all the generated code
>> to the src folder, by annotating the package with:
>>
>> @GenModel(modelDirectory="/<your-project-name>/src")
> Yes. If you direct the source to a folder different from the project's
> preferences for the "src-gen" folder (so configuring that preference to
> something else also works), then things like a clean build will not
> delete all your sources and you get merging as normal.
>> then one can follow @generated_NOT approach like before.
> Exactly.
>>
>> If one uses this technique which generates everything in the src
>> folder, does this effect the edit and editor bundles that are created
>> when the appropriate attributes are set to in the properties view?
>> (Edit Directory, Editor Director)
> Only the model project supports a "src-gen" folder (because you can't
> specify any of the hand written logic you might write for item providers
> or the editor via Xcore)...
>>
>> For example if I set the Edit Directory to /<your-project-edit-name>/src
>> Will the @generated_NOT approach work in my itemProviders to prevent
>> the code from being overwritten?
> It will always work.
>> And conversely if I set the Edit Directory to
>> /<your-project-edit-name>/src-gen the code is always overwritten?
> No, it will always merge (unless generated into the model project)...
>>
>>
>>
>>
>> Or
>>> about how to separate such modifications (for which there is no current
>>> mechanism, though I've been toying with the idea of reusing the approach
>>> used by the Xtext folks where the generator can detected that for
>>> generated implementation class XImpl there exists an XImplCustom that
>>> extends XImpl and then everywhere XImpl is referenced, XImplCustom is
>>> referenced instead...
>>
>> What you suggest would be the best, but for the current release what
>> is the best practice to use both src and src-gen source directories to
>> keep gen code and custom code separate?
> There isn't one.
Well that makes the choice clear!
>> For example to initialize my date when it is first created by the
>> parent itemProvider?
> Only hand written mechanisms are possible.
>>
>>
>>
>>>> Are there any examples?
>>>>
>>>> * thanks for creating the very cool Xcore!
>>> It would be nice to have more time to evolve the features of Xcore more
>>> quickly....
>>
>> Ed - You have done so much already thanks.
> Separation of generated and hand written source is kind of a religious
> issue, so while I have my own perspective on that,
Can you share your perspective?
> supporting other perspectives seems wise...
For me it is nice to see where to focus changes. My src vs the
generated src-gen. And version control only my stuff. So for my above
use case I will mod the edit bundle source at the most but it would be
nice to keep my model impl all src-gen. (I have yet to get into
Validation and Constraints but I have my fingers crossed.)
Having a single model that specifies structure and behaviour is very big
step forward. (And Xbase is a very interesting language.) Also worth
mentioning is the clarity of the Xcore DSL. I have already used Xcore
directly with non-technical clients to dynamically model business
process. Even the non-technical clients understood the structural model.
Later at a presentation with senior management we presented the
ecorediag and everyone understood the concepts. Great!
|
|
|
| Re: [XCORE] Initializing a feature [message #1280021 is a reply to message #1279986] |
Sat, 29 March 2014 17:13 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
John,
Yes, Xcore is very nice provides a complete and concise overview of
every last detail which you don't get any other way (because import
things are hidden off in the properties). And of course picture gives a
simple perspective that text never can. Here's my view on the
hand-written code issue:
http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
On 29/03/2014 4:50 PM, John E. Conlon wrote:
> Ed,
>
> Comments in line...
>
> On 03/28/2014 11:23 PM, Ed Merks wrote:
>> John,
>>
>> Comments below...
>>
>> On 28/03/2014 9:01 PM, John E. Conlon wrote:
>>> Ed
>>>
>>> See in line comments...
>>>
>>>
>>> On 03/27/2014 11:34 PM, Ed Merks wrote:
>>>> John,
>>>>
>>>> Comments below.
>>>>
>>>> On 28/03/2014 2:54 AM, John E. Conlon wrote:
>>>>> Couple of Xcore related questions and a comment...
>>>>>
>>>>> I have an Xcore class and datatype:
>>>>>
>>>>> abstract class Event {
>>>>> Date date
>>>>> String comments
>>>>> }
>>>>>
>>>>> type Date wraps Date
>>>>> create {
>>>>> try {
>>>>> if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
>>>>> } catch (ParseException parseException){
>>>>> throw new RuntimeException(parseException)
>>>>> }
>>>>> }
>>>>> convert {
>>>>> if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
>>>>> }
>>>>>
>>>>>
>>>>> * How can I initialize the date feature in the child Event classes to
>>>>> the current date when the event is first constructed?
>>>> You can't and probably shouldn't. After all, such classes are also
>>>> created during copying and deserialization, in which case such a
>>>> date is
>>>> typically overwritten later (and if not should not have been set,
>>>> because it wasn't set in the original object)...
>>>
>>> Your right. I used this hack before and got away with it, but I must
>>> reform my ways...
>>
>>>
>>> This is a convenience for the user, they create a new event and it has
>>> the current date.
>>> So if not in the constructor, where is the best place for setting the
>>> date to the current date on user creation?
>> If users are involved, it's generally something you'd do in the item
>> providers...
>>> Would it be in the Packages' FactoryImpl in the create methods or in
>>> the Event parents ItemProvider in the x.x.x.edit.provider package?
>> The latter, though it can be a significant amount of manual updating of
>> the child descriptors if the type of child can be created in many
>> different contexts...
>
> Yep, just what I thought. Wanted to make sure that I wasn't missing
> some subtlety or a 'cooler' way to do it;-)
>
>>>>>
>>>>> * What is the best way to keep the src-gen code separated from the
>>>>> src
>>>>> authored source code?
>>>> The Xcore builder automatically keeps all the generated Java source
>>>> separate. Is this question about modifying that generated source?
>>>
>>> Have seen previous threads showing how to move all the generated code
>>> to the src folder, by annotating the package with:
>>>
>>> @GenModel(modelDirectory="/<your-project-name>/src")
>> Yes. If you direct the source to a folder different from the project's
>> preferences for the "src-gen" folder (so configuring that preference to
>> something else also works), then things like a clean build will not
>> delete all your sources and you get merging as normal.
>>> then one can follow @generated_NOT approach like before.
>> Exactly.
>>>
>>> If one uses this technique which generates everything in the src
>>> folder, does this effect the edit and editor bundles that are created
>>> when the appropriate attributes are set to in the properties view?
>>> (Edit Directory, Editor Director)
>> Only the model project supports a "src-gen" folder (because you can't
>> specify any of the hand written logic you might write for item providers
>> or the editor via Xcore)...
>>>
>>> For example if I set the Edit Directory to
>>> /<your-project-edit-name>/src
>>> Will the @generated_NOT approach work in my itemProviders to prevent
>>> the code from being overwritten?
>> It will always work.
>>> And conversely if I set the Edit Directory to
>>> /<your-project-edit-name>/src-gen the code is always overwritten?
>> No, it will always merge (unless generated into the model project)...
>>>
>>>
>>>
>>>
>>> Or
>>>> about how to separate such modifications (for which there is no
>>>> current
>>>> mechanism, though I've been toying with the idea of reusing the
>>>> approach
>>>> used by the Xtext folks where the generator can detected that for
>>>> generated implementation class XImpl there exists an XImplCustom that
>>>> extends XImpl and then everywhere XImpl is referenced, XImplCustom is
>>>> referenced instead...
>>>
>>> What you suggest would be the best, but for the current release what
>>> is the best practice to use both src and src-gen source directories to
>>> keep gen code and custom code separate?
>> There isn't one.
>
> Well that makes the choice clear!
>
>>> For example to initialize my date when it is first created by the
>>> parent itemProvider?
>> Only hand written mechanisms are possible.
>>>
>>>
>>>
>>>>> Are there any examples?
>>>>>
>>>>> * thanks for creating the very cool Xcore!
>>>> It would be nice to have more time to evolve the features of Xcore
>>>> more
>>>> quickly....
>>>
>>> Ed - You have done so much already thanks.
>> Separation of generated and hand written source is kind of a religious
>> issue, so while I have my own perspective on that,
>
> Can you share your perspective?
>
>
>> supporting other perspectives seems wise...
>
>
>
> For me it is nice to see where to focus changes. My src vs the
> generated src-gen. And version control only my stuff. So for my
> above use case I will mod the edit bundle source at the most but it
> would be nice to keep my model impl all src-gen. (I have yet to get
> into Validation and Constraints but I have my fingers crossed.)
>
>
> Having a single model that specifies structure and behaviour is very
> big step forward. (And Xbase is a very interesting language.) Also
> worth mentioning is the clarity of the Xcore DSL. I have already used
> Xcore directly with non-technical clients to dynamically model
> business process. Even the non-technical clients understood the
> structural model. Later at a presentation with senior management we
> presented the ecorediag and everyone understood the concepts. Great!
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [XCORE] Initializing a feature [message #1280035 is a reply to message #1280021] |
Sat, 29 March 2014 17:38 |
| Eclipse User |
|
|
|
Ed,
> Here's my view on the
> hand-written code issue:
> http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
As always I am grateful for enlightenment. +1 for pragmatic code
generation.
On 03/29/2014 12:13 PM, Ed Merks wrote:
> John,
>
> Yes, Xcore is very nice provides a complete and concise overview of
> every last detail which you don't get any other way (because import
> things are hidden off in the properties). And of course picture gives a
> simple perspective that text never can. Here's my view on the
> hand-written code issue:
> http://ed-merks.blogspot.de/2008/10/hand-written-and-generated-code-never.html
>
>
>
> On 29/03/2014 4:50 PM, John E. Conlon wrote:
>> Ed,
>>
>> Comments in line...
>>
>> On 03/28/2014 11:23 PM, Ed Merks wrote:
>>> John,
>>>
>>> Comments below...
>>>
>>> On 28/03/2014 9:01 PM, John E. Conlon wrote:
>>>> Ed
>>>>
>>>> See in line comments...
>>>>
>>>>
>>>> On 03/27/2014 11:34 PM, Ed Merks wrote:
>>>>> John,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> On 28/03/2014 2:54 AM, John E. Conlon wrote:
>>>>>> Couple of Xcore related questions and a comment...
>>>>>>
>>>>>> I have an Xcore class and datatype:
>>>>>>
>>>>>> abstract class Event {
>>>>>> Date date
>>>>>> String comments
>>>>>> }
>>>>>>
>>>>>> type Date wraps Date
>>>>>> create {
>>>>>> try {
>>>>>> if (it != null) new SimpleDateFormat("yyyy- MM-dd").parse(it);
>>>>>> } catch (ParseException parseException){
>>>>>> throw new RuntimeException(parseException)
>>>>>> }
>>>>>> }
>>>>>> convert {
>>>>>> if (it != null) new SimpleDateFormat("yyyy-MM-dd").format(it);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> * How can I initialize the date feature in the child Event classes to
>>>>>> the current date when the event is first constructed?
>>>>> You can't and probably shouldn't. After all, such classes are also
>>>>> created during copying and deserialization, in which case such a
>>>>> date is
>>>>> typically overwritten later (and if not should not have been set,
>>>>> because it wasn't set in the original object)...
>>>>
>>>> Your right. I used this hack before and got away with it, but I must
>>>> reform my ways...
>>>
>>>>
>>>> This is a convenience for the user, they create a new event and it has
>>>> the current date.
>>>> So if not in the constructor, where is the best place for setting the
>>>> date to the current date on user creation?
>>> If users are involved, it's generally something you'd do in the item
>>> providers...
>>>> Would it be in the Packages' FactoryImpl in the create methods or in
>>>> the Event parents ItemProvider in the x.x.x.edit.provider package?
>>> The latter, though it can be a significant amount of manual updating of
>>> the child descriptors if the type of child can be created in many
>>> different contexts...
>>
>> Yep, just what I thought. Wanted to make sure that I wasn't missing
>> some subtlety or a 'cooler' way to do it;-)
>>
>>>>>>
>>>>>> * What is the best way to keep the src-gen code separated from the
>>>>>> src
>>>>>> authored source code?
>>>>> The Xcore builder automatically keeps all the generated Java source
>>>>> separate. Is this question about modifying that generated source?
>>>>
>>>> Have seen previous threads showing how to move all the generated code
>>>> to the src folder, by annotating the package with:
>>>>
>>>> @GenModel(modelDirectory="/<your-project-name>/src")
>>> Yes. If you direct the source to a folder different from the project's
>>> preferences for the "src-gen" folder (so configuring that preference to
>>> something else also works), then things like a clean build will not
>>> delete all your sources and you get merging as normal.
>>>> then one can follow @generated_NOT approach like before.
>>> Exactly.
>>>>
>>>> If one uses this technique which generates everything in the src
>>>> folder, does this effect the edit and editor bundles that are created
>>>> when the appropriate attributes are set to in the properties view?
>>>> (Edit Directory, Editor Director)
>>> Only the model project supports a "src-gen" folder (because you can't
>>> specify any of the hand written logic you might write for item providers
>>> or the editor via Xcore)...
>>>>
>>>> For example if I set the Edit Directory to
>>>> /<your-project-edit-name>/src
>>>> Will the @generated_NOT approach work in my itemProviders to prevent
>>>> the code from being overwritten?
>>> It will always work.
>>>> And conversely if I set the Edit Directory to
>>>> /<your-project-edit-name>/src-gen the code is always overwritten?
>>> No, it will always merge (unless generated into the model project)...
>>>>
>>>>
>>>>
>>>>
>>>> Or
>>>>> about how to separate such modifications (for which there is no
>>>>> current
>>>>> mechanism, though I've been toying with the idea of reusing the
>>>>> approach
>>>>> used by the Xtext folks where the generator can detected that for
>>>>> generated implementation class XImpl there exists an XImplCustom that
>>>>> extends XImpl and then everywhere XImpl is referenced, XImplCustom is
>>>>> referenced instead...
>>>>
>>>> What you suggest would be the best, but for the current release what
>>>> is the best practice to use both src and src-gen source directories to
>>>> keep gen code and custom code separate?
>>> There isn't one.
>>
>> Well that makes the choice clear!
>>
>>>> For example to initialize my date when it is first created by the
>>>> parent itemProvider?
>>> Only hand written mechanisms are possible.
>>>>
>>>>
>>>>
>>>>>> Are there any examples?
>>>>>>
>>>>>> * thanks for creating the very cool Xcore!
>>>>> It would be nice to have more time to evolve the features of Xcore
>>>>> more
>>>>> quickly....
>>>>
>>>> Ed - You have done so much already thanks.
>>> Separation of generated and hand written source is kind of a religious
>>> issue, so while I have my own perspective on that,
>>
>> Can you share your perspective?
>>
>>
>>> supporting other perspectives seems wise...
>>
>>
>>
>> For me it is nice to see where to focus changes. My src vs the
>> generated src-gen. And version control only my stuff. So for my
>> above use case I will mod the edit bundle source at the most but it
>> would be nice to keep my model impl all src-gen. (I have yet to get
>> into Validation and Constraints but I have my fingers crossed.)
>>
>>
>> Having a single model that specifies structure and behaviour is very
>> big step forward. (And Xbase is a very interesting language.) Also
>> worth mentioning is the clarity of the Xcore DSL. I have already used
>> Xcore directly with non-technical clients to dynamically model
>> business process. Even the non-technical clients understood the
>> structural model. Later at a presentation with senior management we
>> presented the ecorediag and everyone understood the concepts. Great!
>>
>>
>>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 15:37:04 GMT 2024
Powered by FUDForum. Page generated in 0.03781 seconds |
] 
Search
Help
Register
Login
Home
