[richfaces-issues] [JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5

[Juraj Húska (JIRA)]

    [ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807139#comment-12807139 ] 

Juraj Húska edited comment on RF-12802 at 9/25/13 4:05 AM:
-----------------------------------------------------------

Couple of questions which arose during refactoring, and we would like to know your opinion on that:

1. Do we want methods to throw exceptions when certain condition is not met, or we want them to be no operation in such situations. Consider e.g.:
{code}
public void hide() {
  if (!getMenuPopupInternal().isDisplayed()) {
      throw new IllegalStateException("You are attemting to hide the " + getNameOfFragment() + ", however, no "
      + getNameOfFragment() + " is displayed at the moment!");
  }
  browser.findElement(Utils.BY_HTML).click();
  waitUntilIsNotVisible().perform();
}
{code}

Which throws exception when an user is attempting to hide already hidden popup panel.

2. Do we want to have {{AdvancedInteractions advanced()}} method in the API ? For some Page Fragments, not doing so, means breaking program to interface rule.

E.g. using {{TextInputComponentImpl}} in {{RichFacesAutocomplete}} [here|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments/src/main/java/org/richfaces/tests/page/fragments/impl/autocomplete/RichFacesAutocomplete.java#L108].

In order to allow user to call {{advanced}} on the returned object, we have to return concrete implementation, not the interface. Is that OK for that component ?

I would not add {{advanced}} to API, because not all implementation (not our, but possible future implementations) needs such method.
                
      was (Author: jhuska):
    Couple of questions which arose during refactoring, and we would like to know your opinion on that:

# Do we want methods to throw exceptions when certain condition is not met, or we want them to be no operation in such situations. Consider e.g.:
{code}
public void hide() {
  if (!getMenuPopupInternal().isDisplayed()) {
      throw new IllegalStateException("You are attemting to hide the " + getNameOfFragment() + ", however, no "
      + getNameOfFragment() + " is displayed at the moment!");
  }
  browser.findElement(Utils.BY_HTML).click();
  waitUntilIsNotVisible().perform();
}
{code}

Which throws exception when an user is attempting to hide already hidden popup panel.

# Do we want to have {{AdvancedInteractions advanced()}} method in the API ? For some Page Fragments, not doing so, means breaking program to interface rule.

E.g. using {{TextInputComponentImpl}} in {{RichFacesAutocomplete}} [here|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments/src/main/java/org/richfaces/tests/page/fragments/impl/autocomplete/RichFacesAutocomplete.java#L108].

In order to allow user to call {{advanced}} on the returned object, we have to return concrete implementation, not the interface. Is that OK for that component ?

I would not add {{advanced}} to API, because not all implementation (not our, but possible future implementations) needs such method.
                  
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
>                 Key: RF-12802
>                 URL: https://issues.jboss.org/browse/RF-12802
>             Project: RichFaces
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: build/distribution
>    Affects Versions: 5.0.0.Alpha1
>            Reporter: Pavol Pitonak
>            Assignee: Brian Leathem
>             Fix For: 5.0.0.Alpha2
>
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira